Incident severity levels: definitions, who declares them and when to assume the worst

What it is

A severity scale classifies an incident by impact and binds each level to a response: who is paged, whether a coordinator role is filled, whether the status page and stakeholders are informed. PagerDuty's public incident response documentation uses SEV-1 to SEV-5 with lower numbers more urgent, states that anything above SEV-3 is automatically a major incident with a more intensive response than a normal incident, and that if you are unsure which level applies you treat it as the higher one, because during an incident is not the time to litigate severities. The Google SRE book's chapter on managing incidents lists broad conditions for declaring: a second team is needed, the outage is visible to customers, or the issue is unsolved after an hour's concentrated analysis; it states that it is better to declare an incident early, find a simple fix and close it out than to spin up the incident management framework hours into a burgeoning problem.

Why it matters

Without a scale, responders argue about whether something "is an incident" while it grows, or escalate everything and exhaust the people paged. Without the assume-the-worst rule, uncertainty delays the response exactly when acting is cheapest.

How to apply

• Write three to five levels in user terms: who is affected, how badly, and whether data or security is involved. Attach to each the paging, coordination and communication actions, so declaring a level triggers work rather than debate.
• Authorise everyone on the rotation to declare an incident and set an initial level. Downgrading later is cheap; the postmortem reviews the choice.
• Include a level for "no user impact yet, but coordinated work is needed", so precautionary declarations are normal rather than embarrassing.
• Record the level and every change to it in the incident timeline with a timestamp and reason.
• Rehearse the moment of choosing a level in game days and role-plays, not only the technical fix.

Pitfalls

Tying severity to a business metric nobody can compute at 3 a.m. Letting only managers declare. Using severity as a blame signal, which makes people under-declare. Skipping the postmortem review that keeps the scale calibrated.