Severity Levels

Industry-standard SEV definitions, who responds at each level, and how to avoid sev-creep.

Overview

Severity levels triage the response

Get severity wrong and you either page the on-call SRE for cosmetic UI bugs (alert fatigue) or wait for business hours to fix a billing outage (career-limiting).

The industry-standard four tiers

Used by Google, Meta, Atlassian, PagerDuty and most major tech companies.

SEV-1 (Critical) — Service unavailable for many users; data loss occurring; revenue impact > $X/min — Page IC immediately, full incident command, status page within minutes, leadership informed — Checkout flow fully down; customer-data breach in progress; major region down
SEV-2 (Major) — Service degraded for many users; key feature unavailable; revenue impact present but not catastrophic — Page on-call immediately; IC may or may not be needed; status page and internal Slack updates — Fleet-wide search latency spike; a major feature returning errors; one of three regions degraded
SEV-3 (Minor) — Some users or features affected; workarounds exist; not blocking for most — Ticket the on-call team; investigate in business hours; status page may not be needed — A non-critical feature is slow; a small subset hitting an edge-case error
SEV-4 (Cosmetic) — No real customer impact — Ticket at standard backlog priority — Wrong tooltip on a dashboard widget; typo in an internal admin tool

The classification framework

For each incident, the IC asks four questions:

1. How many users are affected? — Few / many / most / all
2. What's the user impact? — Cosmetic / degraded / blocked / data loss
3. Is there a workaround? — Yes / no
4. What's the revenue or SLA impact? — None / minor / major / catastrophic

> [!TIP] The SRE Book's framing: be conservative when escalating (page even if unsure) and aggressive when declassifying (drop the SEV once impact is contained).

Sev-creep

Sev-creep is every issue getting classified as SEV-2 because nobody wants to be wrong. The pager fires on cosmetic bugs, SREs burn out, and real SEV-1s get lost in the noise.

Quarterly SEV-distribution review — A healthy team has 1-2 SEV-1s a year, 5-15 SEV-2s, more SEV-3+. Thirty SEV-1s a year means sev-creep
Promote and demote during the incident — SEV-2 that turns out to hit one customer drops to SEV-3; SEV-3 that reveals data loss jumps to SEV-1
Annual review of SEV definitions — Customer base, revenue and contracts change, so thresholds must too

> [!WARNING] Rate of fire matters. A 5-minute SEV-1 once a quarter is fine. A 5-minute SEV-1 every week is a SEV-1 in disguise: the underlying brittleness is the SEV-1.

Key concepts

SEV-1: Critical. Many users blocked, data loss, or major revenue impact. Page immediately, full IC structure, status page.
SEV-2: Major. Many users degraded, key feature unavailable. Page on-call, partial IC structure.
SEV-3: Minor. Some users affected, workarounds available. Ticket; investigate during business hours.
SEV-4: Cosmetic. No real user impact. Standard backlog ticket.
Sev-creep: Tendency to classify incidents at higher SEV than warranted. Causes alert fatigue. Combat with regular distribution reviews.
Promote/demote during incident: SEV is not fixed. If impact narrows, demote. If impact widens or data loss is discovered, promote.

When to use it

Active incident — assigning SEV in the first 60 seconds dictates response
On-call training — every new SRE needs to know the SEV ladder
Quarterly review — SEV distribution is a team-health metric
Customer SLA negotiations — what a SEV-1 means is partly contractual

Interview questions

Walk me through SEV-1 to SEV-4 and how you classify.
How do you decide whether an incident is SEV-1 vs SEV-2?
How do you prevent sev-creep?