Here's a question that quietly decides how bad your worst night gets: when something breaks, who gets woken up, and how fast?
If the answer is "everyone, always" or "whoever notices first," you don't have an answer — you have a coin flip. Severity levels are how you replace that coin flip with a decision you made calmly, in advance, instead of frantically at 2am. They're one of the highest-return things a small team can write down, and one of the most commonly skipped, so let me make the case and then show you how to do it without over-engineering it.
What severity levels actually do
A severity level is a label you attach to an incident — SEV1, SEV2, and so on — but the label itself is worthless. What makes it matter is what's attached to the label:
- Who gets paged. A SEV1 wakes the on-call engineer and probably their backup. A SEV4 doesn't wake anyone; it waits for morning.
- How fast. Severity sets your response-time expectation. SEV1 means now. SEV3 means this week.
- How loudly you communicate. A SEV1 gets a status-page update and a customer-facing message; a SEV4 gets a line in a ticket.
Without this mapping, every incident competes for the same attention, and the loudest or most recent one wins regardless of how much it matters. The whole job of a severity scale is to make sure a cosmetic typo doesn't wake five engineers, and a real outage never sits in a queue behind that typo. As PagerDuty puts it in their severity levels reference, lower numbers are more urgent, and the level determines how aggressively you're allowed to respond.
SEV1 through SEV5, with examples
The numbers run from most severe (SEV1) to least (SEV5). Here's how the industry generally defines them, with concrete examples so they're not abstract.
SEV1 — Critical
The system is down, or data is at risk, or there's a security breach. Core functionality is unavailable to a large set of users and there's no workaround.
Examples: the whole app returns errors; checkout is completely broken; the database is unreachable; customer data is exposed; a security incident is in progress.
Response: page immediately, all hands. Wake the on-call, escalate fast if unacknowledged, pull in whoever you need, and communicate publicly. This is the one you build everything else around.
SEV2 — High
A major feature is down or severely degraded for many users, but the system as a whole is still up. Painful, widely felt, but not a total outage.
Examples: search is broken but the rest of the app works; logins fail for a subset of users; a core API is timing out intermittently; severe slowness across a key flow.
Response: page during waking hours, urgent. Many teams page SEV2 at any hour too — your call, based on impact.
SEV3 — Moderate
Minor or partial impact. Something's degraded or a non-critical feature misbehaves, but users can still get their work done.
Examples: a secondary feature is broken; performance is worse than usual but usable; an export occasionally fails.
Response: handle during business hours. Create a ticket, fix it in the normal flow. Nobody gets woken.
SEV4 — Low
Low impact, and a workaround exists. Annoying, not urgent.
Examples: a minor bug with a known workaround; a non-critical background job is delayed; a small UI glitch that doesn't block anything.
Response: queue it. Normal prioritization, no special urgency.
SEV5 — Cosmetic
No customer impact at all.
Examples: a typo, a misaligned button, an internal-only log warning, slightly-off copy.
Response: backlog it. This is the level that, mislabeled as anything higher, is how teams start waking people up for nothing.
How a small team should define theirs
Now the most important part, and the part where most "severity guides" lead you astray: you almost certainly do not need five levels.
Five levels is a big-org tool. It exists because large companies need fine-grained distinctions to route work across many teams and many on-call layers. A team of three to ten doesn't have that problem. What you have is a much simpler question — does this wake someone, and how fast? — and you can answer it with three levels:
- Critical — page now, wake someone. (Your SEV1, plus the worst SEV2s.)
- Urgent — fix today, but it can wait for morning. (SEV2/SEV3.)
- Low — handle in the normal flow. (SEV4/SEV5.)
Three levels, each with an unambiguous "what happens." That's a system your whole team can hold in their heads, which means it's a system they'll actually use. A perfect five-level matrix that lives in a doc nobody opens during an incident is worse than three levels everyone knows by heart. Start with three. Add a fourth only when you feel a real gap, not because a template told you to.
Map severity to escalation, on-call, and comms
A severity level only does its job if it's wired to behavior. The mapping is the whole point:
- Severity to paging. Critical pages the on-call immediately and escalates to the backup if unacknowledged. Low doesn't page at all — it files a ticket. This is exactly what an escalation policy is for: ordered levels with timeouts, where critical incidents climb fast and low ones never start.
- Severity to on-call. Critical can pull in the secondary and beyond. If you haven't set up a rotation yet, that's the prerequisite — here's how to set up an on-call rotation for a small team.
- Severity to communication. Critical gets a status-page update and a customer message; lower severities get internal notes. Match the volume of your communication to the severity, so you don't cry wolf publicly over a minor blip — or go silent during a real one.
When severity is mapped this way, the label works for you. Tag an incident Critical and the right people get the right page at the right speed, without anyone deciding in the moment.
Common mistakes
Three traps, all common, all avoidable:
Everything is a SEV1. When every incident is critical, none of them are. Your on-call learns that "SEV1" means "maybe important," starts treating pages as noise, and now the actual SEV1 gets the same shrug as the typo. Reserve the top level for things that genuinely warrant waking people. Scarcity is what makes it mean something.
Severity inflation. The cousin of the above. People bump severity to get faster attention for their thing, and over time the whole scale drifts upward until it's useless. Push back on this. The scale only works if a SEV2 today means what a SEV2 meant last month.
No written definitions. If severity lives only in people's heads, two engineers will classify the same incident two different ways, and you'll argue about the label while the system burns. Write the definitions down — one paragraph per level, with examples from your product. Five minutes of writing now saves a debate during your next outage.
Make severity actionable with Tallwatch
Severity is a decision; tooling is what turns the decision into action. In Tallwatch you build escalation policies with up to ten ordered levels, each pointing at channels and/or on-call schedules, each with its own timeout, where an acknowledgement stops the cascade. So your "Critical" definition stops being a word in a doc and becomes a real path: page the on-call, wait, escalate to the backup, climb to a louder channel — exactly as fast as that severity demands.
And the incident timeline keeps severity honest after the fact. Every incident records when it opened, when someone acknowledged, and when it resolved — and it auto-resolves when the service recovers. That record lets you look back and ask the questions that improve your scale: were we right to call that a SEV1? Did the page reach someone in time? Severity definitions get better when you can see how they played out.
One thing worth saying plainly: trustworthy severity starts with trustworthy alerts. If your pages are full of false alarms, no severity scale can save you — your team will distrust the Critical label the same way they distrust everything else. That's why Tallwatch pages by consensus, so a single bad region never fires a false SEV1. Get the signal right first, then let severity decide what to do with it.
Write your levels down, keep them few, wire them to behavior, and don't let everything become a SEV1. That's the entire discipline — and it's the difference between an incident process that protects your team and one that just stamps a label on the chaos.