Incident severity levels exist for one reason: so that a responder who was asleep ninety seconds ago can decide, without debate, how many people to wake up. Everything else (the reporting, the SLA math, the quarterly review slides) is downstream of that one decision. If your scale cannot be applied in under thirty seconds by someone with partial information and no context, it is not a severity scale. It is documentation.

Most teams write their severity definitions once, during a calm afternoon, and never test them against a real page. The result is a set of levels that read beautifully in the wiki and get ignored in the channel, where the actual classification happens by vibes: whoever speaks first says "this feels like a SEV1" and the rest of the response follows. This post covers how to define severity levels that hold up under pressure, how to wire them into on-call routing so the classification actually changes behavior, and how to tell whether your scale is working.

What incident severity levels are actually for

The word "severity" invites teams to think they are measuring how bad something is. That framing is the root of most broken scales. Badness is a continuum, it is partly subjective, and at minute three of an incident nobody knows where on the continuum they are. A scale built on badness produces arguments.

Severity is a routing decision, not a judgment

A better framing: severity is the answer to "who needs to be involved, how fast, and with what authority." It is an operational lever. SEV1 does not mean "this is very bad." It means "page the on-call, page the secondary, open a bridge, notify leadership, and expect to break normal change process." Those are concrete consequences, and they are the thing the responder is really choosing between.

Once you accept that framing, a lot of design questions answer themselves. You need exactly as many levels as you have distinct response patterns. If SEV2 and SEV3 trigger the same page, the same people and the same comms, you have one level with two names, and your responders will guess between them at random.

The three questions a good scale answers

Every level in your scale should make three things unambiguous:

Who gets woken. Primary on-call only, or primary plus secondary, or the whole service team, or leadership and legal as well.
What process is suspended. At high severity, change freezes, approval gates and normal deploy review get bypassed in favor of speed. Responders need explicit permission to do that, written down in advance.
Who has to be told, and how often. Internal stakeholders, customer support, the public status page, regulators in some industries. Communication cadence is part of the severity definition, not a separate policy.

If a level in your current scale does not change the answer to at least one of those three questions compared to the level below it, delete the level.

Why most severity scales fail under pressure

Four failure patterns account for nearly every unusable scale I have seen. They are easy to spot once you know what to look for.

The vocabulary problem: "critical" means nothing at 3 a.m.

Definitions written as adjectives fail. "SEV1: critical business impact. SEV2: significant business impact. SEV3: moderate business impact." Critical, significant and moderate are not observable. The responder cannot look at a dashboard and determine which adjective applies, so they fall back on gut feeling, and gut feeling at 3 a.m. skews toward whatever the responder was last yelled at about.

Replace adjectives with observable conditions. "Checkout error rate above 5 percent" is observable. "Login unavailable in any region" is observable. "Significant impact" is not. Google's SRE material makes a similar argument about alerting: the useful criterion is whether a signal is symptomatic of real user pain and whether a human must act on it now, not how dramatic it sounds. The SRE Workbook chapter on incident response is worth reading in full if you are designing this from scratch.

Too many levels

Five levels plus a "SEV0 for truly existential events" is a common shape, and it is one or two levels too many. Humans classify reliably into three or four buckets. Past that, the boundaries blur and the distribution collapses: teams with six levels almost always find that ninety percent of their incidents land in two of them, and the rest exist to make the taxonomy feel complete.

Four levels is the sweet spot for most engineering organizations, and three works fine for teams under about fifty engineers.

Severity that depends on knowing the cause

This one is subtle and it is the most damaging. If your SEV1 definition says "a database failure affecting all customers," the responder cannot classify until they know it is the database. But classification has to happen first, because classification is what summons the people who will figure out the cause. A scale that requires diagnosis to apply is a scale that gets applied twenty minutes late.

Write every definition in terms of symptoms that are visible from the outside: what users cannot do, what is erroring, what is slow, what is unreachable. Cause never belongs in a severity definition.

No default, so declaration gets delayed

When responders are unsure, and the scale gives them no guidance about what to do while unsure, they wait. Waiting is the expensive failure mode. An incident that sits unclassified for fifteen minutes while someone investigates quietly is fifteen minutes of response capacity you did not use.

Fix this with an explicit rule: when in doubt, declare one level higher than your instinct, and downgrade within fifteen minutes if the impact turns out to be narrower. Downgrading has to be culturally free. If people get teased for a "false SEV1," they will stop declaring, and you will lose far more to late declaration than you ever lose to over-declaration.

A severity scale that survives contact with a real incident

Here is a four level scale written to the rules above. Treat it as a starting template and substitute your own observable thresholds, because the specific numbers depend entirely on your product.

SEV1: total or near total loss of a core function

Observable trigger: a primary user journey is unavailable or failing for most users, in one or more regions, with no workaround. Examples: customers cannot log in, cannot complete a purchase, cannot access their data. Also: confirmed data loss or corruption, and confirmed active exposure of customer data.

Response: page primary and secondary on-call immediately, open an incident channel and a bridge, name an incident commander within five minutes, notify the engineering leadership channel automatically, post to the public status page within fifteen minutes. Change freeze on the affected system. Mitigation outranks diagnosis, always.

SEV2: serious degradation with a workaround or partial scope

Observable trigger: a core journey is degraded (elevated errors, latency well outside normal) but mostly functioning, or a non core function is fully down, or a core function is down for a single large customer or a single small region. Also: the incident is currently SEV3 but trending worse and nobody has a fix.

Response: page primary on-call immediately, open an incident channel, notify support so they can answer inbound questions, status page at the responder's discretion. Secondary is informed, not paged. Postmortem still required.

SEV3: contained problem, business hours response

Observable trigger: a minor feature is broken, a background job is delayed beyond its normal window, a single customer reports an issue that is real but not spreading, internal tooling is down. Users are inconvenienced but the product works.

Response: notify the on-call through a non paging channel, handle during business hours, track to resolution in your ticketing system. No bridge, no commander, no status page. Lightweight writeup only if it recurs.

SEV4: noise and near misses worth recording

Observable trigger: something fired, someone looked, nothing was actually broken. A failed canary that rolled back correctly. A flapping alert. A capacity warning with hours of headroom.

SEV4 is optional but useful, because it gives you a place to put near misses instead of silently closing them. The pile of SEV4s is the single best input to alert quality work: it is a list, in your own data, of every time your monitoring interrupted a human for nothing.

Writing definitions responders can actually apply

Use observable signals, with numbers where you have them

Wherever a threshold exists, write it in. "Error rate above 5 percent for five minutes on the checkout service" beats "checkout is significantly degraded" every time, because the responder can verify it on a dashboard in ten seconds. Where you genuinely cannot quantify, use a concrete scenario instead of an adjective: "a customer cannot complete signup" is not a number, but it is still observable.

Be careful not to over-specify. A definition with eleven numbered conditions is a definition nobody reads. Aim for two or three observable triggers per level plus a catch all sentence.

Tie each level to a specific action, not a feeling

Write the response next to the trigger, in the same document, at the same level of detail. The responder is not consulting your severity page out of curiosity. They are consulting it to find out what to do next. If they have to open a second document to learn what SEV1 implies, they will skip the lookup and improvise.

Make declaring up cheap and declaring down normal

State in writing that anyone can declare any severity, including a support engineer, a customer success manager, or someone on their first week. Gatekeeping declaration behind seniority guarantees delay. State equally clearly that downgrading is a routine, expected act that requires no apology, and that the commander can do it unilaterally once scope is understood.

Security incidents: same scale or separate?

Use the same severity scale for routing, with a separate playbook for handling. Security incidents need different steps (evidence preservation, restricted channels, legal and privacy involvement, notification obligations) but they still need to answer the same question about who gets woken, and forcing responders to hold two scales in their head at 3 a.m. is a reliable way to get both wrong. NIST's incident handling guidance, SP 800-61, is a solid reference for the handling side if you are building that playbook.

One important adjustment: for suspected security incidents, the "declare up when unsure" rule matters more, and the incident channel should be private by default, since the scope of exposure is unknown at declaration time.

Severity, priority and urgency are three different things

Teams conflate these constantly and it causes real confusion in tooling, because your monitoring system, your on-call tool and your ticket tracker each use the words slightly differently.

Severity describes the impact happening right now, and determines the response. It is a property of the incident.
Priority describes how the follow up work ranks against everything else in the backlog. It is a property of the remediation ticket, decided after the incident.
Urgency describes how fast the notification must reach a human, and is usually a property of the alert rule.

A SEV1 that is already mitigated can produce a P3 follow up ticket, and that is fine, not a contradiction. A low urgency alert about certificate expiry can, if ignored for long enough, become a SEV1. Keeping these vocabularies separate in your tooling prevents a whole category of argument.

Wiring severity into on-call routing so it means something

A severity scale that lives only in a wiki has no effect on behavior. The classification has to be an input to your paging system, or it is theater. Three integration points matter most.

Declaration should be one command, in the place the work is happening

If declaring an incident requires opening a separate web app, finding the right form, filling in eight fields and clicking through a confirmation, responders will do the work first and declare later, which defeats the purpose. Declaration should be a single action in the tool where the team already is. For most teams that is Slack, which is why Slack-native incident tooling has a real advantage here: with Pagerly the responder declares severity in the channel where the alert landed, and the tool opens the incident channel, pulls in the right on-call rotation for that severity, and starts the timeline automatically. The distance between "I think this is a SEV1" and "the SEV1 response is running" should be one message.

Each severity should map to its own escalation policy

This is the payoff for keeping the number of levels small. SEV1 pages primary and secondary in parallel with a five minute escalation to the engineering manager. SEV2 pages primary with a fifteen minute escalation to secondary. SEV3 posts to a channel and pages nobody. If those three paths are configured in your on-call tool and keyed to severity, then classification automatically produces the right response, and your responders never have to remember the escalation rules at all. They just have to classify correctly, which is a much smaller thing to ask.

Comms cadence should be automated per level

SEV1 in most organizations implies a stakeholder update every thirty minutes, whether or not there is news. That cadence is exactly the kind of obligation that gets dropped during a difficult incident, because the people who remember it are busy. Attach a recurring reminder to the severity level so the incident channel prompts for an update on schedule, and put a named comms lead on SEV1s whose only job is writing those updates. The technical responders should never be the ones drafting customer language mid incident.

Measuring whether your severity levels are working

You can tell whether a scale is healthy from four numbers, all of which you can pull from your incident history.

Distribution across levels. A healthy distribution is roughly pyramid shaped: a handful of SEV1s, more SEV2s, many SEV3s. If ninety percent of your incidents are one level, that level is doing all the work and the others are decoration.
Reclassification rate. Some upgrades and downgrades are healthy and show the scale is being used actively. If nothing ever gets reclassified, people are declaring once and never revisiting. If more than about a third get reclassified, your triggers are too vague.
Time from first signal to declaration. This is the number most worth optimizing, because everything else in the response is gated behind it. Track the gap between the first alert or first customer report and the moment severity was set. If that gap is routinely over ten minutes on serious incidents, your declaration path has too much friction.
SEV1 page acceptance time. If your highest severity pages are being acknowledged slowly, either the routing is wrong or people have learned that SEV1 does not really mean SEV1. Both are urgent problems.

Review these quarterly, not monthly. Severity distributions are noisy over short windows and you will chase phantoms.

Rolling out a new scale without a six month project

Severity redesign has a tendency to become a committee. It does not need to be. A workable sequence:

Week one: pull your last fifty incidents and classify them under the proposed scale, ignoring whatever they were labeled at the time. This takes an afternoon and it will immediately expose triggers that are ambiguous, because you will find yourself unable to classify your own history. Fix those triggers before anyone else sees the document.

Week two: write the one page version. One page, four levels, trigger and response side by side, no appendices. If it does not fit on one page it will not be read during an incident. Circulate it for comment with a hard deadline, and resolve disagreements by asking "does this change who gets woken?" rather than by consensus.

Week three: configure the escalation policies in your on-call tool so each level routes differently, and make the declaration path a single command. This is the step teams skip, and skipping it is why the previous three attempts failed.

Week four onward: use it, and bring reclassifications to your incident review. The scale will need two or three rounds of adjustment in the first quarter. Expect that, and put a named owner on it so the edits actually happen.

Common edge cases worth deciding in advance

Degraded but not down

Slow is the hardest case, because there is no clean line and the impact accumulates quietly. Decide in advance what latency counts as an outage for your product, write it as a number, and put it in the SEV2 trigger. Otherwise every slow incident becomes a fresh debate about whether it is an incident at all.

Single large customer affected

Many teams instinctively want a revenue-weighted rule here. Resist making it the primary axis, because responders do not know account sizes at 3 a.m. and should not be looking them up mid incident. A workable compromise: scope drives the base severity, and the account team can request an upgrade through a named path. Keep the technical trigger technical.

Vendor outages you cannot fix

An upstream provider going down still gets a severity, because severity describes user impact, not fault. Your users cannot tell the difference between your outage and your vendor's. What changes is the playbook: mitigation means failover, degradation or communication rather than a code fix, and the comms obligation gets heavier because you have less control over resolution time.

The takeaway

Good incident severity levels are short, observable, and wired directly into who gets paged. They describe symptoms rather than causes, they use numbers rather than adjectives, and they have exactly as many levels as you have distinct response patterns. The test is not whether the document is thorough. The test is whether a tired engineer with one dashboard open can classify correctly in thirty seconds and have the right people show up automatically as a result.

If your current scale fails that test, the fix is usually subtraction: fewer levels, fewer words, fewer conditions, and one less click between declaring and responding.