Severity answers one question: how hard do we drop everything? Decide it by customer impact, not by which system broke. Four levels is enough for almost any team — and for a small team, the honest difference is between "wake someone" and "fix it tomorrow".
The matrix
| Level | Customer impact | Response | Tell customers? |
|---|---|---|---|
| SEV1 | Product down or unusable for most customers; data at risk | Immediately, whoever's available — interrupt anything | Yes — status page within 15 min |
| SEV2 | A core feature broken or badly degraded for many customers | Within 30 min, during or outside hours | Yes — status page within 30 min |
| SEV3 | A non-core feature broken, or a core feature for a few customers; workaround exists | Business hours, same day | Usually not the status page — reply directly to affected customers |
| SEV4 | Cosmetic, minor, or single-customer edge case | Backlog | No |
How to use it
- Pick the severity at detection with what you know, and change it freely. A wrong first guess costs nothing; a delayed response does.
- When torn between two levels, pick the higher one. Downgrading later reads fine; upgrading late reads like you weren't watching.
- Severity drives communication automatically. SEV1/SEV2 means a status page entry — not a debate each time. That's a policy decision you make once, calmly, not per-incident at 11pm.
- "Most customers" needs a number for your product. Write your own thresholds into the table (e.g. ">25% of orgs" vs ">3 orgs") so two people can't read the same outage differently.
- Track your SEV1/SEV2 count monthly. If everything is a SEV2, your levels aren't doing their job.