Incident severity should describe current or credible business impact, not how alarming a log message looks.
Incident severity should describe current or credible business impact, not how alarming a log message looks. A shared matrix helps a small team mobilise the right people while keeping routine defects out of the emergency channel. Define levels with examples from your product and make it easy to change a level as evidence develops.
Classify impact across several dimensions
Consider affected customers, critical journeys, financial or data consequences, duration and available workarounds. A problem affecting few customers may still be urgent if it corrupts financial records. Conversely, a noisy internal dashboard may not justify waking the entire team. Record uncertainty and choose a conservative initial response when a serious consequence is plausible.
Write an illustrative matrix
A highest-severity example is an ongoing critical journey failure or suspected serious data-integrity impact requiring coordinated response. A middle level might cover substantial degradation with a limited workaround. A lower level can cover a contained defect suitable for normal prioritisation. These are examples, not a universal standard: attach your own notification rules, decision authority and contractual obligations.
Separate severity from response timing
Severity describes impact; priority and service commitments determine the required action and timing. Name an incident lead, technical responders and communication owner for major events. Define who can declare or downgrade an incident, how backups are contacted and when external suppliers become involved. Keep the matrix short enough to use under pressure.
Review classification after the event
Compare the initial judgement with the final impact and identify missing signals. Update examples when teams repeatedly disagree about a class. Track whether alerts reached someone able to act and whether communication helped customers. A severity label is useful only if it changes behaviour; adding more levels without clear response differences creates debate rather than coordination.
- Related service
- Rollback or hotfix during a production incident
- Application disaster recovery: test RTO and RPO
Frequently asked questions
Is SEV1 always the highest level?
Naming varies. Publish the ordering and meaning used by your organisation.
Can severity change during an incident?
Yes. Record why it changed and notify the people whose response obligations are affected.
Does every security alert require the highest severity?
Assess credibility and potential impact while following the security response process; do not dismiss uncertainty without investigation.
Should customer count decide severity?
It is one factor. Data integrity, money and critical workflows may outweigh raw numbers.
Where should the matrix live?
Somewhere responders can reach during an outage, with links from alerts and runbooks.
Bring the scope. We will help make it buildable.
Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.
Further reading
Rollback or hotfix during a production incident
During an incident, choose the action most likely to restore acceptable service with controlled risk.
Application disaster recovery: test RTO and RPO
A disaster recovery plan is credible when the team can demonstrate restoration of a useful service.
A production runbook a small team can actually use
A runbook should help a responder move from a specific symptom to a safe decision.