Incident Severity Levels: SEV1–SEV5 Explained

The alert fires, three people join the call, and the first ten minutes go to arguing about whether this is a SEV1. The clock on time-to-acknowledge is running, the symptom is unchanged, and nobody has been paged who wasn't already watching.

That argument happens because the team is treating severity as a verdict on how bad things are. It isn't. Incident severity levels are a routing decision — their only job is to determine who gets woken up, how fast, and through which channel. Frame it that way and the debate mostly disappears, because "is this bad?" is a matter of opinion and "does this need to wake someone up right now?" usually isn't.

The severity table

The reference model most teams start from, with the routing decision attached to each level:

Treat this as the reference, not the recommendation — further down I'll argue most teams should collapse it to three levels.

What each severity level actually means

The table gives you adjectives. Adjectives are where classification arguments come from. What you actually need is a test — a question with a yes or no answer that two engineers can apply independently and land in the same place.

SEV1

Is revenue or data at risk right now, for users who are not a subset? Total loss of a core flow, irreversible data damage, or a security exposure. If you find yourself qualifying the blast radius with "for users who…", it isn't a SEV1.

SEV2

Is a core workflow unavailable with no workaround you could describe to a customer over the phone? The blast radius is bounded but large, and the people inside it are fully blocked. A payment method down is a SEV2 if another one works, and a SEV1 if it doesn't.

SEV3

Is there a workaround, and would a customer accept it for a day? Something is broken and users can tell, but there is a path through it. This is the level most incidents actually belong to, and the level teams are most reluctant to use.

SEV4

Would a customer notice if you didn't tell them? If the answer is no, it's a SEV4. Cosmetic defects, internal noise, anything where the cost of the interruption exceeds the cost of the bug.

SEV5

Did any user-facing behaviour change at all? If nothing observable happened, you're recording an event, not responding to an incident.

Why most teams should use three levels, not five

Five levels look rigorous on a wiki page. In practice, SEV4 and SEV5 become a queue with no consumer.

Watch what happens. Someone files a SEV5. Nobody is paged and nobody is notified — that's the design. It lands in a backlog with no owner and no review cadence, and it sits there. Six months later the queue has two hundred items and filing a SEV5 is indistinguishable from filing nothing.

That's worse than not having the level, because you've built the appearance of tracking without the fact of it. People believe the issue is captured. It is captured, in the sense that a message in a bottle is captured.

Use three levels, mapped to the three things you can actually do about an incident: page someone now, notify the team, or file a ticket. That's the entire decision space. A severity scale with more entries than you have distinct responses is a taxonomy, not a routing system.

The one condition that justifies five: a support contract that defines severity tiers with per-tier response obligations. When the levels are externally imposed and legally meaningful, you keep all five because a customer is holding you to them. That's a real reason. "It seems more thorough" is not.

Response time targets per severity

Attach numbers, or the levels are decorative:

These turn the measurements in MTTR, MTTD, MTBF: Incident Metrics Explained into commitments. A mean time to acknowledge tells you what happened; a per-severity target tells you what was supposed to happen, which is what makes the metric actionable rather than merely interesting.

One distinction worth being pedantic about: a target is not an SLA obligation. An internal four-hour SEV1 resolution target is an operational goal you set for yourselves. It creates no contractual duty and no service credit. Teams that publish internal targets in customer-facing documents have accidentally negotiated against themselves — see SLA vs SLO vs SLI for why the layers need to stay separate.

The escalation ladder

Severity decides who gets the first notification. The escalation ladder decides what happens when that person doesn't answer:

The eight minutes at step 2 matters more than the structure. An escalation timer shorter than realistic acknowledgement time manufactures noise. If it takes four minutes to surface from sleep, find a laptop, and open the alert, a three-minute escalation guarantees the secondary is paged on every single incident — and within a month both people have learned that a step-2 page carries no information. Measure your actual acknowledgement times and set the timer above the 75th percentile.

The ladder should also differ per severity rather than being global. A SEV3 that reaches the engineering manager after thirty minutes is how you teach managers to mute the channel — and once muted, it stays muted for the SEV1 too. Configuration details are in the alert escalation policies guide.

Routing severity to the right channel

Channel choice is not a cosmetic preference. It is the implementation of severity:

A SEV1 delivered by email is not a SEV1 — you've declared an emergency and routed it to a medium with a multi-hour read latency. The top level needs channels that interrupt: a phone call or SMS reaches someone asleep, and a paging tool like PagerDuty or Opsgenie adds its own on-call schedule. Slack is right for SEV2 and SEV3 and wrong for SEV1, for the same reason email is. The full channel list covers the rest.

A worked example

One incident, start to finish:

09:14  External HTTP checks fail from three regions. Alert fires.
09:14  Classified SEV1 — checkout returning 5xx, no known blast radius yet.
09:15  Primary on-call paged by phone and SMS.
09:17  Acknowledged. Time to acknowledge: 3 minutes.
09:26  Root cause identified: one payment provider timing out.
       Card payments failing, PayPal completing normally.
09:27  Downgraded to SEV2 — large subset, but a workaround exists.
       Step-4 manager escalation cancelled. Status page set to "degraded".
09:41  Provider failover completed. Checkout fully restored.
10:05  Downgraded to SEV3 for follow-up work on the failover timeout.

Two things that downgrade bought. The step-4 manager page never fired, so someone who couldn't have helped stayed asleep and will still trust the ladder next month. And the recorded duration now reflects real blast radius — thirteen minutes at SEV1, not fifty-one — instead of preserving a worst-case guess made in minute one with no data.

Classifying high on first contact is correct. Staying there is not.

Classification mistakes that cost you

Severity inflation. Everything becomes a SEV1 because nobody wants to be the person who under-called it. The tell is a SEV1 rate that doesn't drop during quiet weeks — if your severity distribution is flat regardless of what's actually happening, the levels have stopped carrying information and you're just paging everyone every time.

No downgrade path. Incidents open at SEV1 and stay SEV1 through resolution because reclassification isn't anybody's job. Your mean time to resolve is now the average of your worst-case guesses rather than your actual outcomes, which makes the incident metrics you report unusable for deciding where to invest.

The reporter sets the severity. The person who noticed is the worst-placed individual to judge blast radius. They have a sample size of one and no view of how many other users share their experience. Severity belongs to the responder or incident commander, who can see the monitoring data.

Severity based on component, not blast radius. "The database is down" is not a severity. A read replica failing behind automatic failover and a primary failing without it are the same component and completely different emergencies. Classify by what users experience, never by which box is unhealthy.

No documented tie between severity and error-budget spend. If a SEV2 doesn't visibly consume budget, severity is a label with no consequences attached. Error budgets are what convert an incident classification into a decision about whether to keep shipping.

Wiring it up

In Xitoring, the pieces map directly. Triggers carry a severity, so a failing check routes according to how bad the condition is rather than firing one undifferentiated alert. Escalation policies define the ladder with per-step delays, so an unacknowledged SEV1 climbs to the secondary and then the lead on its own. Notification channels are assigned per severity, which is where the routing table above becomes configuration instead of documentation — over twenty channel options are available, from phone and SMS through to paging tools and chat.

Maintenance windows handle the other half: planned work that would otherwise enter the severity system as a false SEV1 and burn the ladder's credibility.

The free plan covers 8 checks without a credit card, which is enough to wire a real ladder against the handful of checks that would genuinely justify waking someone up.

Related reading

• MTTR, MTTD, MTBF: Incident Metrics Explained — the measurements these severity targets turn into commitments
• Alert Fatigue: Smart Alerting for On-Call Teams — how to stop the noise that makes severity meaningless
• Error Budgets Explained — what a SEV1 actually costs you
• SLA vs SLO vs SLI: What's the Difference? — why an internal target is not a contractual promise
• How to Report Uptime SLAs on a Status Page — communicating severity to customers without overpromising
• Alert Escalation Policies — configuring the ladder in Xitoring
• What Is Uptime Monitoring? The 2026 Guide — where the detection that starts the clock comes from

Frequently Asked Questions

What is the difference between SEV1 and P1?

In most organisations they're the same concept under two naming conventions — SEV from the severity tradition, P from priority. Where a team genuinely uses both, severity describes impact (how many users are affected and how badly) while priority describes what gets worked on next, which also weighs effort and what else is in flight. A SEV3 with a one-line fix can reasonably be a P1. The failure mode is treating the two as interchangeable and then arguing about which is authoritative mid-incident.

Who decides the severity of an incident?

The on-call responder or incident commander, not the person who reported it. A reporter has a sample size of one: they know their own request failed and nothing about whether that's universal or unique to their account. Blast radius is only visible from monitoring data. Keep the initial classification fast and explicitly provisional — you classify to route the alert, then correct once you can see the scope.

Can an incident's severity change while it is open?

Yes, and it should, in both directions. Downgrading when the blast radius turns out narrower than feared is not admitting an error; it's the system working. Refusing to downgrade is what corrupts your incident metrics, because every incident then records its worst-case duration. Record a timestamp for each change so that time-spent-per-severity stays accurate, and make sure a downgrade also cancels any pending escalation steps.

How many severity levels should we have?

Three, for most teams — mapped to the three distinct responses available: page someone now, notify the team, file a ticket. A scale with more entries than you have responses produces levels nobody triages, and an untriaged level is worse than a missing one because it looks like coverage. Keep five only when a support contract imposes them with per-tier response obligations, in which case the levels are externally defined and you don't get a choice.

Does severity level affect our SLA?

Not directly. An SLA is a contractual promise with a remedy attached; severity is an internal routing mechanism with no contractual weight. The two connect only when the contract itself defines severity tiers and ties response obligations to them — exactly the situation where a five-level scale earns its keep. Keep internal targets and contractual commitments in separate documents; SLA vs SLO vs SLI covers why collapsing those layers gets expensive.