Most severity matrices fail in the one moment they matter: at 02:00, when a tired engineer has to decide whether to wake anyone. This one is written so the level is readable off customer impact alone: no judgement call about root cause, no guessing how bad it might get.
What you get
Four severity levels defined by what a customer cannot do, not by which system broke
Response, update cadence, and escalation target for each level
A tie-breaker rule for the cases that sit between two levels
A downgrade and upgrade procedure, so severity can change as you learn more
How to use this template
1
Define levels by customer impact, not component. "Database down" is not a severity. "Customers cannot complete checkout" is. Write each level as something a non-engineer could confirm from the outside, because at 02:00 that is the only thing anyone can assess quickly.
2
Attach a clock to every level. A level with no response time is a label, not a commitment. Each row needs a time to acknowledge, an update cadence, and the role that gets escalated to. If SEV1 and SEV2 have the same times, you have three levels, not four.
3
Write the tie-breaker down. The argument is always between two adjacent levels. Pick the default now (round up, and let the incident commander downgrade) and record it on the sheet. Deciding this during an incident costs you the first ten minutes.
4
Review it against your last ten incidents. Classify the last ten retrospectively. If more than half land in one level, your thresholds are wrong and the matrix will not discriminate when it matters.
What's inside
Here's a preview. Unlock the free download to get all 4 sections (3 more below).
Severity levels
One row per level. The customer impact column is the only one anyone should need to read to classify an incident.
Level
Customer impact
Example
Acknowledge within
Update cadence
Escalate to
SEV1
Core workflow unavailable for all or most customers, or confirmed data loss
Checkout fails for every customer; production database unreachable
5 min
Every 30 min
Incident commander + engineering lead + exec on-call
SEV2
Core workflow degraded or unavailable for a subset, with no workaround
Login fails for SSO users only; one region fully down
Most postmortems produce a document nobody reads and actions nobody owns. This one forces the three things that actually reduce repeat incidents: a timeline built from timestamps rather than memory, contributing factors stated without naming a person, and action items with an owner and a date.
A rota is more than a list of names against dates. This template covers the parts that cause real pages to go unanswered: who the secondary is, what happens when nobody acknowledges, and what the outgoing engineer must hand over.
Escalation fails when it depends on someone deciding to escalate. Time-based triggers remove the judgement call, so a ticket moves because the clock says so rather than because an agent felt stuck enough to ask.
A table that maps incident impact to a severity level, and each level to a response time, update cadence, and escalation path. Its job is to remove the judgement call from the first minute of an incident so the response starts immediately.
How many severity levels should we have?
+
Four is the common choice and works for most teams. Fewer than three cannot discriminate between an outage and a cosmetic bug; more than five means levels blur together and people default to the middle. The test is whether each level has a genuinely different response time.
What is the difference between severity and priority?
+
Severity describes how bad the impact is and is set from the customer's side. Priority describes what you work on first and also weighs effort, risk, and what else is in flight. A SEV3 affecting a contract-critical customer can legitimately outrank a SEV2.
Who decides the severity of an incident?
+
Whoever notices it first should set an initial level, because waiting for an authority wastes the opening minutes. The incident commander then owns it and is usually the only role allowed to downgrade.
