Define Incident Severity Levels

Classify incidents by customer impact and urgency, assign paging and communication rules, and avoid every alert becoming a SEV1.

beginner~20 minoperationsincident-responsereliability

Objective

Give responders a shared, fast way to decide who to page, how often to communicate, and when to escalate.

Environment

An incident process and on-call rotation
A paging tool with severity-based routing
A status page or customer communication channel
An incident tracker with timestamps and owners

Steps

1. Define severity by impact

Write criteria for SEV1–SEV4 using customer impact, data loss, security exposure, and scope. Avoid using internal cause as the primary severity signal.

Expected state: Two responders classify the same incident the same way.

2. Set paging and escalation

Map each severity to who is paged, how quickly, and when to escalate to engineering or leadership.

Expected state: A SEV1 pages the on-call immediately and escalates within a defined window.

3. Define communication cadence

Specify internal updates and customer communication intervals per severity, with an owner for each.

Expected state: Stakeholders know when the next update will arrive.

4. Review and adjust

Reclassify during the incident if impact changes, and review classifications in the postmortem.

Expected state: Severity reflects current impact, not the initial guess.

Decision points

Is a security incident always SEV1?

Yes, regardless of confirmed impact
Only when data or access is confirmed compromised

Use a security-specific severity that starts high when exposure is plausible and adjusts as facts are confirmed.

Who can declare a SEV1?

Any on-call engineer
Only an incident commander

Allow any on-call engineer to declare; waiting for permission delays response.

Expected outcome

Responders classify incidents consistently, page the right people, and communicate on a predictable cadence.

Verification

Run a tabletop exercise with three scenarios and compare classifications across responders; check paging routes and update cadence against the matrix.

Cleanup

Update the matrix with lessons from real incidents, archive the exercise results, and train new on-call engineers.

Severity is about impact

A severity level answers: how many users are affected, how badly, is data at risk, and is the impact growing? A database failover that users never notice is not the same as a checkout outage. Define the levels with concrete examples and thresholds so two responders reach the same classification.

SEV1: broad outage, data loss, or active security exposure; page now
SEV2: major feature degraded or a large subset affected; page now
SEV3: limited impact with a workaround; business-hours response
SEV4: minor or cosmetic; backlog

Paging follows severity

SEV1 and SEV2 should page the on-call immediately, with an escalation path if there is no acknowledgement. SEV3 may create a ticket during business hours. The matrix should state who communicates with customers and how often. A SEV1 without a communication owner creates a second problem.

Reclassify as facts change

Initial reports are uncertain. Start with the impact you can confirm, and adjust severity as scope becomes clear. A SEV3 that turns out to affect all users should escalate immediately. Review classifications in the postmortem; a pattern of misclassification means the criteria or training need work.