A practical severity ladder for production incidents — definitions, escalation expectations, response times, and worked examples for SEV-1 through SEV-4.
Severity answers one question: how much attention does this deserve right now? Teams drown when severities inflate ("everything is a SEV-1") and lose customers when they deflate. Your ladder matters less than enforcing its boundaries — ours below works for most B2B/SaaS shops and doubles as intake for postmortem triage.
| Level | Definition | Response | Postmortem? |
|---|---|---|---|
| SEV-1 | Core revenue/user flow fully down or data integrity threatened | All-hands, exec notified, status page within 15 min | Always, reviewed publicly |
| SEV-2 | Major feature degraded or partial outage for many users | On-call + secondary, hourly updates | Always |
| SEV-3 | Minor feature broken, workaround exists, batch jobs failing | On-call during business hours | Optional, threshold-based |
| SEV-4 | Cosmetic defects, internal tooling degradation | Ticket queue | No |
SEV-1: payment processing returns 502s for all EU customers for 22 minutes. Revenue actively burning; status page updated; exec bridge open.
SEV-2: order-history endpoint slow (8–30s) for ~40% of sessions while checkout stays functional. Degradation with revenue exposure nearby — frequent downgrade target, resist it.
SEV-3: nightly warehouse sync fails twice weekly due to flaky credentials refresh; data lands late but complete once retried manually.
SEV-4: admin dashboard shows wrong sort order on one table view.
When documenting reviews afterward, severity drives required sections — see our full postmortem guide.
Paste your incident timeline and get this exact structure filled out in ~90 seconds.