Incident Severity Classification

Definition

Incident severity classification is a small, published set of levels — commonly SEV1 to SEV4 — each defined by customer impact and each attached to a specific response: who is paged, who leads, who communicates, how often updates are issued, and whether a formal review follows. The scale exists so that the first person to see a problem does not have to negotiate the response while the problem is still growing.

Why It Matters

The expensive minutes in most incidents are the first ten, and they are usually spent deciding whether this is serious. An engineer sees elevated errors, wonders whether waking the database lead is justified, checks another dashboard, messages a colleague who is asleep, and twelve minutes disappear. A severity scale removes that deliberation by pre-answering it. It also protects people in the other direction: a defined SEV3 means nobody is paged at 3 am for something that can wait for business hours, which is what keeps an on-call rotation sustainable.

A Workable Scale

1. SEV1 — critical. Core function unavailable or data at risk for many customers. Immediate page, incident commander assigned, customer communication within 30 minutes, updates every 30 minutes, blameless review mandatory.
2. SEV2 — major. Significant degradation or a critical function broken for a subset. Page during and outside hours, named lead, hourly updates, review required.
3. SEV3 — minor. Limited impact with a workaround. Business-hours response, tracked to resolution, no page.
4. SEV4 — low. Cosmetic or single-user issues. Normal backlog handling.

Two rules make the scale work. Anyone may declare any severity, and over-declaring is explicitly not punished. And severity can be downgraded once impact is understood — declaring SEV1 and reclassifying at minute eight is a success, not an error.

Real-World Example

A logistics SaaS platform had a four-level scale defined in a wiki page nobody had read since onboarding. During a checkout outage, the first responder judged it "probably a SEV2" because only one region was affected, so no incident commander was appointed and no customer notice went out. The outage was in fact global for anyone using a particular payment method — around 34% of revenue — and ran for 71 minutes before someone senior noticed the revenue graph and escalated to SEV1.

The blameless review found the definitions were written in infrastructure language ("multiple availability zones affected") rather than customer language, so the responder had no way to map what they saw to a level. The rewrite defined each level by customer-visible outcome — "customers cannot complete a purchase" — added a revenue-impact hint, and put the scale on a single card in the incident channel topic. Median time to declare across the next quarter fell from roughly 14 minutes to under 4.

Practical Lessons Learned

• Define severity by customer impact, not infrastructure state. Responders can see symptoms, not architecture diagrams.
• Make over-declaration safe and cheap. If declaring SEV1 triggers an executive inquest, people will hesitate exactly when hesitation costs most.
• Four levels is plenty. Six-level scales produce arguments about the boundary between them.
• Put the scale where the incident happens. A wiki page is not a control; a pinned card in the incident channel is.
• Track time-to-declare as a metric. It is often a bigger lever than time-to-fix.

Expert Tips

• Add a plain-language example to each level drawn from a real past incident. Examples classify faster than criteria.
• Automate what the declaration does: creating the channel, paging the rota, opening the timeline document. Manual choreography loses minutes.
• Review a sample of last quarter's incidents against the scale. Systematic under-classification is common and easy to see in hindsight.
• Tie communication obligations to severity explicitly, so customer updates are not a separate judgement call under pressure.
• Let the incident commander, not the engineer fixing it, own severity changes during the incident.

Common Mistakes

• Writing severity definitions in internal system terms that responders cannot map to symptoms.
• Treating a SEV1 declaration as an accusation, which trains people to under-declare.
• Having no defined communication or review obligations per level, so the scale changes nothing.
• Allowing severity to drift upward silently without appointing a commander.
• Maintaining the scale in documentation only, never in the tooling that runs the response.

Key Takeaways

• Severity exists to pre-decide the response, not to describe the fault.
• Define levels by customer impact in plain language, with real examples.
• Anyone can declare; over-declaring must be safe.
• Attach paging, leadership, communication and review obligations to each level.
• Measure time-to-declare — it is often where the minutes go.

Related Concepts

Works with Incident Commander Role, Incident Management, Blameless Postmortem, and Alert Fatigue Management.