Incident Severity Levels: How to Define SEV1 to SEV5
A severity scale decides how loudly to respond. Defined well, it removes argument during an incident. Defined badly, it is either ignored or abused.
An incident severity level is a label that states how serious an incident is and, by agreement, what response it receives. A level translates a judgement about impact into actions: who is paged, who leads, who is told and how quickly an update is due.
Severity is used under pressure by people who have little time. The scale therefore needs to be small, concrete and tied to what customers experience, not to how worried the responder feels.
Common scales
Several conventions are in common use. Many software teams use SEV1 to SEV4 or SEV1 to SEV5, where SEV1 is the most serious. Some add SEV0 above it for a catastrophic event. IT service management uses priority levels P1 to P5, derived from impact and urgency. Some teams prefer plain words such as critical, major, minor and low, which need no decoding. The convention matters less than having one and using it consistently.
Atlas offers four presets: SEV1 to SEV5, SEV0 to SEV5, ITIL P1 to P5, and plain words such as Critical and Minor. You can edit the levels, their response targets and whether each one pages, or build your own with your own names and ranks.
Write criteria a stranger could apply
Each level needs criteria that two people would apply the same way. Tie them to customer impact and scope. The following is an illustration to adapt, not a standard.
- SEV1, critical: a core service is unavailable or unusable for most customers, or there is confirmed loss or exposure of data. Respond immediately, page the responders at any hour, name an incident commander and update stakeholders on a short, fixed cycle.
- SEV2, major: a core function is seriously degraded or unavailable for a significant group, or a major customer is blocked. Page the responders, and update on a regular cycle.
- SEV3, moderate: a non-core function is degraded or a workaround exists. Handle during working hours unless it worsens.
- SEV4, minor: a cosmetic or low-impact issue. Track as ordinary work.
Separate severity from impact
Two ideas are often merged. Severity says how seriously to treat the incident and who to wake. Impact says what customers experience: nothing, a degraded service, a partial outage or a full outage. They usually move together but not always. A full outage of an internal tool at midnight may be low severity. A quiet data exposure may have no visible customer impact and still be the most serious event of the year.
Atlas records both. Severity drives who is paged. Impact drives what customers are told. Keeping them apart avoids the situation in which a team must misstate one to get the other right.
Attach actions to each level
A level without actions is a label. For each level, decide:
- Whether it pages, and at what urgency. Atlas distinguishes pages that wake people and override quiet hours, notifications that do not, and records that notify nobody.
- The target time to acknowledge and the target time to mitigate.
- Whether a commander is required and which other roles are filled.
- The update cadence and the audience for updates.
- Whether a review is required afterwards.
Changing severity during an incident
Severity is a judgement based on what is known, and it changes as more is learned. Most incidents start lower and rise as impact is confirmed, and some start high and are stood down. Raise it readily and lower it only with evidence. Record each change on the timeline with the reason.
When unsure, choose the higher level. Raising severity later loses time that standing down never costs. Each Atlas incident stores the rank it was declared at, so changing the scale later does not alter what an old incident meant.
Mistakes to avoid
- Too many levels. Responders cannot hold seven definitions in mind at three in the morning. Four or five is enough.
- Criteria based on feelings. "Serious" is not a criterion. "More than a stated share of users cannot sign in" is.
- Using severity to set priority in the ordinary backlog. Severity governs response, not planning.
- Punishing a responder for declaring too high. That teaches people to under-declare.
- Never reviewing the scale. After each incident, ask whether the level matched the experience.