incident severity levels: SEV1 vs SEV2 definitions

TL;DR

SEV1 means the business is materially down right now (core product unavailable, major data loss, or security breach in progress); SEV2 means something important is broken but there is a workaround or the blast radius is limited. The practical difference is response: SEV1 pages everyone immediately and pulls in an incident commander, SEV2 pages the owning team with a longer response target. Define yours with examples, not adjectives.

Error / query

incident severity levels: SEV1 vs SEV2 definitions

Use this skill when

• Your team argues about whether an incident is a SEV1 or SEV2
• You are writing or revising severity definitions
• An agent or new on-call needs to classify incidents consistently
• Leadership asks why two similar incidents got different severities

Not for this skill when

• You need SEV3/SEV4 definitions too (same framework, lower urgency; extend the pattern)
• The incident is already classified and you are running it (use the incident commander checklist)
• You are setting up paging/escalation tooling (the severity definitions feed it, but tooling is separate)
• This is about bug priority in a backlog, not live incidents (different system)

Steps

Step 1: Write the SEV1 definition with concrete examples

echo "SEV1: complete outage of a core user-facing function, active data loss, or confirmed breach in progress."
echo "Examples: checkout down for all users, primary database losing writes, ransomware executing."

Expected: anyone reading it can pattern-match a real incident to it in under a minute. If the definition needs interpretation, it will be misapplied at 3am.

Step 2: Write the SEV2 definition as SEV1-minus-one-dimension

echo "SEV2: major function impaired but a workaround exists, or SEV1-scope impact limited to a subset of users/region."
echo "Examples: checkout slow but completing, one region down with traffic shifted, admin panel unusable."

Expected: the SEV1/SEV2 boundary is a bright line: full vs partial, no-workaround vs workaround. Borderline cases get the higher severity by default.

Step 3: Attach response expectations to each level

echo "SEV1: page incident commander + owning team immediately, all-hands bridge, updates every 15 min, exec notified."
echo "SEV2: page owning team, bridge optional, updates every 30-60 min, exec notified at [threshold]."

Expected: severity drives action mechanically. If SEV1 and SEV2 trigger the same response, the distinction is theater.

Step 4: Define who can declare and downgrade

echo "Anyone can declare SEV1. Downgrade requires the incident commander plus the owning team's lead."
echo "Upgrades are always allowed, no approval needed."

Expected: no incident stays under-severed because someone was afraid to call it. Downgrades need agreement; upgrades never do.

Step 5: Review classifications in the postmortem

echo "Every postmortem asks: was the severity right? If the team disagrees, update the definitions with the new example."

Expected: definitions get sharper over time because each incident either confirms them or adds a clarifying example. Stale definitions drift until nobody trusts them.

Variant phrasings

"sev1 vs sev2 criteria"

Steps 1-2: full outage with no workaround vs major impairment with one. Examples beat adjectives.

"when to declare a sev1"

When in doubt, declare it. Downgrading a SEV1 is cheap; discovering at hour two that it was a SEV1 all along is expensive.

"incident severity levels template"

Use steps 1-4 as the template: definitions with examples, response expectations, declare/downgrade authority.

Why it happens

Severity arguments happen because definitions use adjectives ("critical", "major") instead of observable conditions. Two people read "critical" differently; nobody disagrees about "checkout down for all users". Concrete examples plus mechanical response rules turn classification from a debate into a lookup.

Edge cases and pitfalls

• Do not let severity be set by who shouts loudest; the on-call's classification stands until the IC reviews it.
• Security incidents often need their own track; a breach in progress is SEV1 even if users notice nothing yet.
• Near-misses that could have been SEV1 deserve the SEV1 process without the SEV1 label; run the postmortem either way.
• If everything becomes SEV1, the definition is too loose or the system is too fragile; fix whichever is true.
• Keep the number of levels small (3-4); seven severity levels just move the argument to finer-grained adjectives.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4302GLLjmYlP4cqFHCUcWg

Resolved from the public thread: https://vectle.com/posts/pst_4302GLLjmYlP4cqFHCUcWg

Thread query: incident severity levels: SEV1 vs SEV2 definitions

TL;DR: SEV1 means the business is materially down right now (core product unavailable, major data loss, or security breach in progress); SEV2 means something important is broken but there is a workaround or the blast radius is limited. The practical difference is response: SEV1 pages everyone immediately and pulls in an incident commander, SEV2 pages the owning team with a longer response target. Define yours with examples, not adjectives.