Incident Classification Template

Four levels (Critical, High, Medium, Low) work well for most product teams. Three levels are too coarse and lead to frequent debates. Five or more levels add unnecessary complexity. The goal is that any engineer can classify an incident in under two minutes with minimal ambiguity.

Classify during the incident, within the first 10 minutes. An initial classification drives the response: who gets notified, what SLAs apply, and whether an incident commander is assigned. You can reclassify after the incident if the initial assessment was wrong. What you cannot do is wait until after resolution to decide how seriously to take it.

Classify by the highest-impact type. If a performance degradation (OPS-03) was caused by a DDoS attack (SEC-05), classify it as SEC-05 because that drives the correct response (security team involvement, potential law enforcement notification). Document both types in the incident record.

An incident is an unplanned disruption or degradation of a live service. A bug is a defect in code that may or may not be causing an active disruption. Not all bugs are incidents (a UI alignment issue is a bug, not an incident). All incidents caused by software defects contain bugs, but the incident response process handles the immediate disruption while the bug fix addresses the underlying defect.

Track three metrics: classification accuracy (percentage of incidents correctly classified on first assessment), mean time to classify (minutes from detection to severity assignment), and escalation accuracy (percentage of escalations that were appropriate for the severity). Review these quarterly and adjust criteria where accuracy drops below 80%.