Incident Severity Levels Explained

Severity is how your team agrees on how bad an incident is and how fast to respond. Without shared definitions, every outage becomes a debate while customers wait.

This guide gives you a severity framework you can adopt today — and wire into on-call paging, status-page comms, and escalation policies.

What is incident severity?

Severity is a label for customer and business impact at a point in time. It answers:

• How many people are affected?
• Is a core workflow blocked?
• Do we need to page someone now?
• Should customers hear from us publicly?

Severity is not the same as priority (importance to the business roadmap) or urgency (how fast someone should look). In practice, severity combines both for operational incidents.

Why severity matters

Clear severity levels help you:

In Incido, severity drives notification urgency and pairs with escalation-policy routing — so definitions in this guide should match what you configure in your org.

The four-level model (recommended)

Most teams do well with four levels. More than five usually adds confusion.

Critical (SEV-1)

Examples: Production API unavailable · Payment or auth down · Active security breach with customer data at risk

Response: Page immediately · Assign incident commander within minutes · Status update within 15 minutes · Log everything on the timeline

High (SEV-2)

Examples: Checkout success rate below threshold · Regional outage · Sustained 5xx spike on primary API

Response: Page immediately · Public update within 30 minutes if customer-visible · Commander recommended

Medium (SEV-3)

Examples: Non-critical feature flaky · Internal tooling down · Single-tenant edge case

Response: Handle in business hours unless agreed otherwise · Status page only if externally visible

Low (SEV-4)

Examples: Cosmetic UI bug · Staging issue · Benign monitor flake

Response: Track as ticket or Low incident · No paging · No status page

Decision tree (use in the first 2 minutes)

Paying customers blocked on a core workflow?
  └─ YES → Critical
  └─ NO → Core feature degraded for many users?
            └─ YES → High
            └─ NO → Limited impact or workaround?
                      └─ YES → Medium
                      └─ NO → Low

When in doubt during an active incident, round up — you can always downgrade once impact is clearer.

Real incident examples

Example A — API gateway returns 503 for all users

Timeline sketch:

Example B — Dashboard charts slow but app usable

Example C — Typo in admin-only settings label

Common mistakes

1. Too many levels — SEV-1 through SEV-7 sounds precise; nobody remembers the difference.
2. Severity by who reports it — CEO email ≠ Critical unless impact matches.
3. Never downgrading — Scope shrinks; severity should too.
4. Same paging for every level — Creates alert fatigue; route Medium differently in escalation policies.
5. No link to status page — If customers are affected, severity should trigger comms expectations.

Free template

Copy our severity matrix template into your wiki, or download the full Engineering Incident Toolkit.

How software helps

Tools do not replace judgment — they enforce consistency. Incido lets you define severity levels with colors and urgency, route escalation policies by severity, and publish status-page updates from the same incident record. When severity and paging stay aligned, responders spend less time debating and more time fixing.