A severity scale exists to answer one question: what happens now? If two levels produce the same response, you have one level with extra bureaucracy.
Define by response, not by feeling
Critical: wake anyone, any hour; start coordination; update the status page immediately. High: page the on-call person; handle now. Medium: notify through a quiet channel; handle during working hours today. Low: record it. The definition writes itself: an incident is critical if it warrants waking multiple people.
Anchor each level with concrete examples
Critical: nobody can log in; checkout is down during trading hours; data is being written incorrectly. High: checkout fails for a subset of payment methods; p99 latency ten times normal. Medium: a non-critical feature is broken; a report did not generate. Low: a cosmetic bug. Keep this list in your runbook and add to it after each incident.
Severity inflation and how to stop it
Every scale drifts upward. Make the higher levels cost something visible, so people think before selecting them. Review the severity distribution monthly — if eighty percent of your incidents are high, your scale has collapsed to one level. Downgrading during an incident should be normal and blameless.
The automated incident problem
Most monitoring assigns a fixed severity to incidents it creates automatically, so that field carries almost no information. Route by source instead of by severity: subscribe loud channels to the checks that warrant waking someone, and quiet channels to everything else. The routing decision moves to where the knowledge lives.
Four levels is usually right
Three is too coarse. Five produces indistinguishable adjacent levels. Four maps cleanly onto the four distinct responses most organisations have: wake everyone, wake one person, handle today, handle eventually.
The one-sentence test
If you cannot describe a different action for two adjacent levels, merge them.