Skip to content
Back to Operations & SRE

Severity Mapping

Map every incident to a severity (SEV1-SEV4) based on user and business impact, not technical cause.

Why

Severity drives everything downstream — who gets paged, how fast you must respond, whether customers are notified, and how much the postmortem is scrutinized. If severity is assigned by technical cause ("the DB crashed, that's SEV1"), you page the DBA at 3am for a crash that hit a read replica with zero user impact. If it's assigned by user and business impact ("0.1% of checkouts failing = SEV2, revenue down = SEV1"), the right people respond at the right urgency. The mapping must be written down before the incident, because at 3am nobody can calmly assess "is this revenue-impacting"; a pre-defined table turns a judgment call into a lookup, which is both faster and more consistent across on-call engineers.

When

Before the first incident. Revisit whenever the business model, user base, or service architecture changes enough to shift impact thresholds.

How

1. Define 4 severity levels by impact, not cause
   - SEV1: revenue down OR >10% of users failing OR data loss/security breach
   - SEV2: degraded for 1-10% of users OR a key feature broken with workaround
   - SEV3: minor feature broken, workaround easy, <1% of users
   - SEV4: cosmetic or internal-only, no user impact

2. Pre-compute the impact thresholds for your business
   - "revenue down" = checkout error rate >1% for 5m (you know your revenue/min)
   - "10% of users" = a region down that serves 10% of traffic
   - Write these as concrete numbers, not adjectives

3. Map each alert to a default severity
   - The alert rule includes the severity label based on the impact it implies
   - During the incident, the IC can upgrade/downgrade with a reason

4. Tie severity to response expectations
   - SEV1: page, ack <5m, war room, customer comms, postmortem required
   - SEV2: page, ack <30m, postmortem required
   - SEV3: ticket, next business day, postmortem optional
   - SEV4: ticket, fix when convenient, no postmortem

5. Review severity calls in postmortems
   - "Was this SEV2 or SEV3?" — calibrate the table from real incidents
   - Drift toward over-severity (everything SEV1) defeats the urgency signal

Example

# severity-table.md — pre-defined, looked up during incidents
| Impact                                    | Severity | Response          |
|-------------------------------------------|----------|-------------------|
| Checkout error rate >1% for 5m            | SEV1     | page, ack <5m, war room, customer comms |
| Any region 100% down                      | SEV1     | page, ack <5m     |
| Auth down (nobody can log in)             | SEV1     | page, ack <5m     |
| Checkout error rate 0.1-1%                | SEV2     | page, ack <30m    |
| Search down (browse still works)          | SEV2     | page, ack <30m    |
| Email notifications delayed >30m          | SEV3     | ticket, business day |
| Typo on a static page                     | SEV4     | ticket, when convenient |

# Alert rule carries the default severity:
- alert: CheckoutErrorRateHigh
  expr: checkout_error_rate > 0.01
  for: 5m
  labels: { severity: SEV1, team: payments }
# IC can downgrade to SEV2 if investigation shows it's a known flaky upstream
# with a workaround active — but they must state the reason in the incident channel.

Common Problems

  • ⚠Assigning severity by technical cause ("DB crashed = SEV1") rather than user impact — a crashed read replica with zero user impact pages the DBA at 3am.
  • ⚠Everything is SEV1 — when urgency is uniform it carries no information, and engineers stop responding faster to SEV1 than SEV2.
  • ⚠No pre-defined table, so severity is a 3am judgment call — different on-call engineers assign different severities to the same incident, breaking consistency.
  • ⚠Severity doesn't change response behavior — SEV3 and SEV4 both get paged, defeating the purpose of the distinction; tie each level to concrete response expectations.

Best Practices

  • ✓Define severity by user and business impact (revenue, % users affected, data loss), not technical cause — write concrete numbers, not adjectives.
  • ✓Pre-publish a severity table with impact thresholds and response expectations per level; the on-call looks it up instead of judging at 3am.
  • ✓Tie each severity to concrete response behavior (ack time, war room, customer comms, postmortem required) so the level changes behavior, not just a label.
  • ✓Calibrate the table from real incidents in postmortems; watch for drift toward over-severity and re-base when everything becomes SEV1.