Severity Levels

In April 2022, Atlassian's cleanup script deleted data for 400 Jira Cloud and Confluence customers. The root cause postmortem revealed something beyond the technical failure: during the first hour of the incident, nobody had clearly assigned a severity level. Without a severity level, there was no incident commander named, no war room opened, no escalation triggered, and no public status page updated. The response stayed scattered for nearly a full day before organizational coordination caught up.

Severity levels exist to remove judgment from the moment of crisis. When the on-call phone rings at 3 AM and the engineer is half-awake, the system must tell them: this is a SEV1, here is what you do. No debates, no Slack threads asking "is this serious?", no waiting for a manager to weigh in.

The tier system is a coordination tool, not a debugging tool. The fix for a SEV1 and a SEV3 might be the same one-line code change, but the SEV1 brings 6 engineers, an incident commander, a public status page post, and an executive briefing. Without the tier, none of that coordination happens automatically.

Almost every company above 50 engineers uses some variant of a four-tier severity system. The names vary (SEV1-SEV4, P0-P3, Critical-Low) but the structure is the same.

The key insight is that severity drives organizational behavior, not technical behavior. It determines who wakes up, how fast they must respond, what communication channels open, and how much follow-up the incident gets.

Stripe, GitHub, Cloudflare, PagerDuty, and Atlassian (after their 2022 incident) all publish severity matrices that follow this general shape. The numbers differ slightly but the structure is universal.