Incident Severity

Incident severity works as a common language for impact when criteria are written, updated with facts and tied to a proportionate response; a complete service outage affects more customers than a minor display glitch, and a label can communicate that difference quickly. Atlassian describes severity as impact and priority as urgency in its incident guidance and gives its own SEV examples, but other organisations use different levels, so never assume SEV 1 or 3 means exactly the same thing everywhere.

PagerDuty's example severity guide gives different response routes for major and minor incidents, which is an example of one organisation's model, not an external rule for everyone, so adapt the approach to your operation. A fictional company calls an outage affecting all paying customers its highest severity, paging an incident lead, engineers and a communications owner, so the classification triggers a plan rather than merely colouring a dashboard.

Impact can include customer count, lost service, safety, data and financial exposure, and one affected customer may still face serious harm if the function is critical, so avoid using only a percentage threshold. A fictional software firm discovers that 5% of users cannot log in; if those users are all one critical client, the percentage alone may understate importance, so context belongs in the decision.

Potential impact matters when facts are incomplete, since a suspected data exposure may warrant rapid escalation before the full scope is known, and the level should be updated as evidence arrives. A low-severity typo could still be high priority if it misstates a price or creates legal confusion, while a serious issue affecting a small group may compete with a larger emergency, so record both severity and priority.

A fictional hospital app shows a cosmetic layout issue while a separate system loses a patient identification field, and these need different safety responses even if both appeared at the same time, so the rubric should reflect real harm. The scale should define how to classify partial outages and degraded performance, since 'system works slowly' can hide users who cannot complete tasks, so check customer experience, not only infrastructure status.

A classification can change during response, and an incident initially thought local may spread, so the team should upgrade severity without waiting for a formal meeting, while downgrading needs care: restore service and verify impact before declaring the event minor, as a quieter customer channel may simply mean users have given up trying. A rubric should identify who can declare or change levels so staff are not forced to wait for an unavailable executive during an urgent incident, with an escalation route provided.

An incident may have several impacts, as a payment outage causes lost orders and customer support contacts, so record the main severity driver and additional effects. Classification should be quick enough to help action, because arguing over an exact label while customers remain at risk defeats the purpose, so use a provisional higher level when uncertain, then review.

Safety and security incidents may have legal notification duties independent of internal severity labels, so do not assume a low label cancels a statutory requirement, and bring specialists in when triggers may apply. A retrospective can test whether the initial severity was appropriate, asking whether the team paged the right people and updated customers soon enough, and thresholds should be revised based on actual cases.

A business can track incident counts by severity, but classification changes can distort trends, so record when a rubric changes, since a fall in severe incidents may be a reporting change, not improvement. A status message can state the current classification but should describe actual customer effects too, because people outside the response team may not know the internal labels, and plain language prevents a SEV code from becoming a substitute for useful information.