When something breaks, the first question is always the same: how bad is it? The answer shapes everything — who gets woken up, how fast you move, whether you declare a full-blown incident. Severity levels give your team a shared, agreed answer, so the response matches the reality instead of depending on whoever happened to notice.
What severity levels are
Severity levels (often "SEV" levels) classify an incident by its impact — usually on a scale from SEV1 (most severe) to SEV4 or SEV5 (least). They turn a vague "this seems bad" into a clear category everyone understands the same way.
The number drives the response: a SEV1 mobilises the whole team immediately; a SEV4 is a ticket for tomorrow.
A typical severity scale
| Level | Impact | Response |
|---|---|---|
| SEV1 | Critical — full outage, major data loss, security breach | All hands, immediately, 24/7 |
| SEV2 | Major — key feature down, big subset of users affected | Urgent; page on-call |
| SEV3 | Minor — limited impact, workaround exists | Handle in business hours |
| SEV4 | Low — cosmetic, negligible impact | Backlog / next sprint |
(Some teams use SEV5 or different names, but the shape is universal: a small number of clear tiers from "everyone now" to "whenever.")
Why they matter
| Benefit | Why |
|---|---|
| Right-sized response | A typo fix and a full outage get appropriately different urgency |
| Shared language | "It's a SEV1" instantly conveys everything |
| Less alert fatigue | Only high severities page people at night |
| Clear escalation | Severity decides who's pulled in |
| Consistent metrics | Compare incidents fairly over time |
The core value: severity decouples "an incident happened" from "wake everyone up." Without levels, every issue feels either ignorable or like a five-alarm fire. With them, the response is proportional — which protects both your systems and your team's sleep.
How to define yours
- Keep it simple. Three or four levels is plenty; more just causes debate.
- Define by user impact, not technical cause. "Checkout is down for everyone" (SEV1) is clearer than "the payments pod is crashlooping."
- Write examples for each level, so classification is fast and consistent at 3am.
- Tie each level to a response: who's paged, how fast, whether to declare an incident and assign an incident commander.
- Let people upgrade/downgrade as understanding changes mid-incident.
Severity drives the whole response
Severity is the dial that tunes your incident response:
- SEV1/2 → page on-call, assign an incident commander, update the status page, all-hands.
- SEV3/4 → a ticket, handled calmly, no middle-of-the-night heroics.
This is also how you keep your pager trustworthy: only the genuinely severe stuff interrupts people, so when it does, they take it seriously.
The bottom line
| In one line | |
|---|---|
| What | A scale (SEV1–SEV4) classifying incident impact. |
| Why | Match the response to the reality. |
| Define by | User impact, with clear examples per level. |
| Drives | Who's paged, how fast, whether it's all-hands. |
Severity levels are a small bit of process with an outsized payoff: they give everyone a shared "how bad is this?" so the response is always proportional. Define three or four clear tiers by user impact, and your incidents — and your team's nights — get a lot calmer.
Related: Incident response playbook, on-call best practices, alert fatigue.