Incident severity levels are a shared scale, commonly SEV1 to SEV4 or P1 to P4, that classifies an incident by its impact on users and the business. Each level defines objective criteria and the expected response, such as who is paged, how fast, how often stakeholders are updated and whether a postmortem is required.
What are incident severity levels?
Incident severity levels are a classification scheme that tells everyone involved how serious an incident is and what response it deserves. Most organizations use three to five levels, named SEV1 to SEV4 or SEV0 to SEV3, where the lowest number is the most severe. Some ITIL-based organizations use priorities such as P1 to P4 instead, often derived from a combination of impact and urgency.
A severity level is a decision shortcut. Once an incident is declared SEV1, nobody has to debate whether to wake up the database team, open a bridge call or update the status page. The answer is already written down. That is why clear criteria matter more than the exact number of levels.
Example severity matrix
The following matrix is an illustrative starting point. Adapt the criteria and times to your services and contracts.
| Level | Typical criteria | Expected response |
|---|---|---|
| SEV1 (critical) | Core service down or data loss or security breach, many or all users affected, SLA at risk | Page immediately, incident commander assigned, status page update, stakeholder updates every 30 minutes, postmortem mandatory |
| SEV2 (major) | Important feature broken or severely degraded for a significant share of users, workaround hard or missing | Page on-call, dedicated channel, regular updates, postmortem mandatory |
| SEV3 (minor) | Limited degradation, small user group or internal tools affected, workaround available | Handled in business hours, ticket with owner, postmortem optional |
| SEV4 (low) | Cosmetic issue or minimal impact, no urgency | Backlog item |
Good criteria are observable. Instead of "many users affected", define thresholds that monitoring can measure, for example "checkout SLI below 95 percent for 10 minutes" or "error budget burn rate above 14.4". This lets alerts propose a severity automatically and keeps classification consistent across teams.
Severity vs priority
Severity describes impact: how bad is it for users and the business? Priority describes the order of work: what do we fix first? The two usually align during an active incident, but they can diverge. A minor bug in a payroll export can be low severity but high priority the day before payroll runs. Keeping both concepts separate prevents teams from inflating severity just to get attention.
How to define severity levels
- Start from impact dimensions: number of affected users, affected functionality, data integrity, security, financial or contractual exposure.
- Write one-line criteria per level with concrete examples from your own systems.
- Attach response rules: who is paged through on-call, target acknowledgement time, communication cadence, required roles such as incident commander and communications lead.
- Allow quick upgrades and downgrades. Severity reflects current knowledge, and changing it should be easy and logged.
- When in doubt, declare higher. Downgrading a SEV2 to SEV3 costs little. Treating a real SEV1 as SEV3 costs a lot.
- Link each level to runbooks and communication templates so responders can act without searching.
Severity, roles and communication
Severity drives not only who fixes the problem but also who needs to know. For SEV1 and SEV2 incidents, many teams separate three roles: the incident commander coordinates and makes decisions, technical responders investigate and mitigate, and a communications lead keeps stakeholders and customers informed. For lower levels, one person usually covers all three.
Communication rules should be just as concrete as technical ones. Define per level which internal channels are notified, whether customer support receives a briefing, when a public status page entry is required and how often updates are posted, even if there is nothing new to report. Regular, predictable updates reduce interruptions for responders, because stakeholders stop asking for news. After the incident, the final severity is recorded and used to group incidents in reports, so that trends in MTTD and MTTR can be compared per level.
Common mistakes
- Vague criteria such as "important customers affected" that lead to different classifications for the same situation.
- Too many levels, which slows down declaration while people argue about the difference between SEV3 and SEV4.
- Paging for SEV3 and SEV4 out of hours, which contributes to alert fatigue and burnout.
- Using severity to measure team performance, which creates pressure to downgrade incidents.
- Skipping the postmortem for high-severity incidents once the pressure is gone.
- Reporting MTTR across all severities as one number, which mixes very different kinds of incidents.
How Obseria helps
In Obseria incident management, alert rules can set an initial severity based on SLO burn rate and affected services, and responders can change it with a recorded timeline. Severity controls routing, escalation and whether a status page update is proposed. Obseria Intelligence attaches the probable root cause with evidence, and incidents can be synchronized with ITSM tools such as ServiceNow.