## 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
```text
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
```bash
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
```bash
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
```bash
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
```bash
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
```bash
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