What a severity level is
A SEV level expresses how serious an incident isand guides how urgently the team responds
When something breaks, people disagree on whether it needs everyone right now or can wait for tomorrow. That disagreement costs time in both directions: a slow response to a real outage, or an unnecessary all-hands scramble. SEV levels settle the question in advance.
Once a level is agreed, it also decides who gets told, how much other work stops, and whether a postmortem gets written afterwards.
What each level means
Level
Definition
Examples
Response
Postmortem
- SEV1
- DefinitionA critical failure affecting many users. Requires executive reporting and external notice
- ExamplesAn SLA breach caused by a long outage; discovery of a vulnerability that could leak data
- ResponseMajor incident. Appoint an incident commander and notify people inside and outside the company
- PostmortemRequired
- SEV2
- DefinitionA critical failure that leaves many users unable to use the service
- ExamplesAlmost nobody can use the screens, or performance has dropped sharply
- ResponseMajor incident. Appoint an incident commander and respond
- PostmortemRequired
- SEV3
- DefinitionAffects some users, or threatens stability. The owning team should act right away
- ExamplesOne feature is down; a single machine failing takes the system with it
- ResponseThe owning team investigates as its top priority and considers a rollback
- PostmortemOptional
- SEV4
- DefinitionNeeds attention, but users are not affected
- ExamplesDegraded performance or latency, a single machine failure, a non-critical scheduled job failing
- ResponseThe owning team handles it ahead of routine work
- PostmortemOptional
- SEV5
- DefinitionNo effect on use — cosmetic issues and minor bugs
- ExamplesA bug with no immediate impact, a broken layout
- ResponseLog it as a ticket for the owner to pick up
- PostmortemOptional
Definitions, examples and responses are based on the PagerDuty Incident Response Documentation; whether a postmortem is required follows the Atlassian Incident Management Handbook.
Making it work in practice
Set the level in the first message
Waiting for the root cause is too late. Assign a provisional level as soon as the blast radius is visible, and adjust it openly as the investigation changes the picture.
When in doubt, go higher
Under-calling an incident costs more than over-calling one. It is always easy to step a level down later.
SEV1 and SEV2 are not closed until the review is done
For major incidents, writing the postmortem is part of the response, not an optional follow-up.