Incident severity classification

Reference Card

• Origin/Prior Art: ITIL (Information Technology Infrastructure Library) incident management frameworks.
• Related Practices: Incident Command System (ICS), On-call rotation.
• Key Concepts: SEV levels, Customer impact, Escalation matrices.
• Primary Failure Modes: SEV inflation (treating every bug as SEV-1), Vague definitions leading to arguments during outages.

Introduction

When an alert fires at 3:00 AM, the on-call engineer needs to know immediately whether to wake up the VP of Engineering or go back to sleep.

If a system simply reports “Error in billing service,” the response is entirely subjective. One engineer might panic and declare a total outage; another might assume it’s a minor glitch and ignore it.

Incident severity classification solves this by forcing organizations to define business impact ahead of time. It establishes a shared vocabulary - most commonly a scale from SEV-1 (Critical) to SEV-4 (Low) - that instantly dictates the expected response time, the required personnel, and the communication protocols for any given issue.

Mental Model

Think of a hospital emergency room triage desk. If a patient walks in with a scraped knee, they are classified as low priority (SEV-4); a nurse will see them eventually. If a patient is wheeled in with a gunshot wound, they are classified as critical (SEV-1); alarms sound, specialists drop what they are doing, and a trauma team assembles immediately.

The triage classification removes hesitation. It tells the hospital exactly how much resource to deploy without requiring a debate.

Operational Pattern

A standard severity matrix typically looks like this:

• SEV-1 (Critical): Total loss of a core business function. Customers cannot log in, pay, or use the primary product. Significant financial or reputational damage is actively occurring.
  • Response: Immediate. All hands on deck. Executive leadership notified.
• SEV-2 (Major): A core business function is severely degraded, but a workaround exists, or the issue only affects a subset of users.
  • Response: Immediate response from the primary on-call team.
• SEV-3 (Minor): Non-critical feature is broken. No data loss, and the primary business functions operate normally.
  • Response: Handled during normal business hours. Added to the top of the next sprint.
• SEV-4 (Low): Minor bug, cosmetic issue, or a failure in internal tooling that does not impact customers.
  • Response: Added to the general backlog.

Failure Modes

SEV Inflation

If the customer support team is frustrated by slow engineering responses to SEV-3 bugs, they will inevitably start classifying minor bugs as SEV-1 just to get immediate attention. If everything is an emergency, nothing is. This burns out on-call engineers and destroys trust in the alerting system. Organizations must enforce strict definitions and empower the Incident Commander to downgrade inflated severities.

Vague Definitions

If the definition of a SEV-1 is “The system is really broken,” engineers will waste the first 20 minutes of an outage arguing over whether it qualifies as a SEV-1 or SEV-2. Severity definitions must be strictly objective, tied directly to metrics or Service Level Indicators (SLIs). (e.g., “SEV-1: Checkout success rate drops below 95% for 5 consecutive minutes”).

Security

Security incidents (data breaches, active exploitation) are often handled on a separate track from operational incidents because they require different personnel (Legal, PR, InfoSec) and strict confidentiality. Many organizations use a parallel scale (e.g., SEC-1 to SEC-4) to ensure an operational outage does not leak sensitive information to a broad engineering channel.

Operational Guidance

The severity level of an incident is not static. A SEV-2 issue that degrades database performance might escalate into a SEV-1 if the database eventually locks up completely. Conversely, a SEV-1 might be downgraded to a SEV-3 once a temporary mitigation (like failing over to a read replica) stops the immediate bleeding, allowing the team to fix the root cause during normal hours.

Any engineer should have the authority to declare a SEV-1. Do not require managerial approval to trigger a major incident response. It is far better to mistakenly trigger a SEV-1 and downgrade it five minutes later than to let a critical outage burn while waiting for a director to wake up and approve the classification.

Related topics

• Incident command system (ICS)
• Service Level Objectives (SLOs)

Sources & further reading

• PagerDuty Incident Response: Severity Levels - PagerDuty