Incident Severity Level

Severity levels must be defined by business or societal harm, not the underlying technical cause. A SEV-1 incident is not a 'database outage'; it is a 'complete halt of customer transactions' or a 'safety-critical model outputting dangerous instructions.' This alignment ensures that response efforts are proportional to the actual damage, preventing engineering teams from over-prioritizing technically interesting but low-impact bugs. Effective taxonomies map directly to Service Level Objectives (SLOs) and revenue impact.

• SEV-1: Critical business function down, safety incident, or massive data breach.
• SEV-2: Major feature impaired with no workaround, significant user impact.
• SEV-3: Partial, non-critical feature loss with a viable workaround.

Each severity level requires an unambiguous, binary-tested definition to eliminate subjective debate during an incident. A common framework uses a decision tree based on user impact scope and functional degradation. For example, a SEV-1 might be defined as '>50% of users receiving errors on a core transaction flow.' This prevents 'severity creep' where every issue is declared a top-priority emergency. The definition should be a simple checklist that an on-call engineer can apply in seconds.

• Scope: What percentage of users or requests are affected?
• Functionality: Is the system completely down, severely degraded, or slightly slow?
• Workaround: Does a manual bypass exist for the affected users?

A severity taxonomy is useless without automated and manual triggers that enforce it. Each level must be bound to specific response Service Level Agreements (SLAs) for acknowledgment and resolution. A SEV-1 incident typically triggers immediate paging of the on-call Incident Commander, a dedicated war room, and executive stakeholder notification within 15 minutes. These triggers are often linked to error budgets and burn rate alerts, automatically escalating an incident if the Mean Time To Acknowledge (MTTA) is breached.

• SEV-1: Page immediately, war room in 5 minutes, status update every 30 minutes.
• SEV-2: Page immediately, acknowledge in 30 minutes, status update every 2 hours.
• SEV-3: Auto-create ticket, triage during business hours.

AI systems introduce novel failure modes that traditional software taxonomies miss. A dedicated AI severity taxonomy must include criteria for algorithmic harm, such as biased outputs, model hallucination rates, or toxic content generation. A SEV-1 could be triggered by a model exhibiting a sudden spike in racial bias or generating dangerous medical advice, even if the API itself is technically 'healthy.' This requires integrating guardrail violation metrics and drift detection outputs directly into the severity classification logic.

• Safety Violation: Model outputs violating content safety policies.
• Fairness Degradation: A statistically significant increase in a bias metric.
• Factual Grounding Loss: Hallucination rate exceeding a critical threshold.

The taxonomy must define not just the severity but the exact escalation path. A SEV-1 incident automatically pulls in a designated Incident Commander, a Scribe, and a Communications Lead. It also specifies which external stakeholders (e.g., legal, PR, customer support) must be engaged based on the incident's nature. For AI incidents, this often includes a dedicated AI Ethics Officer or a compliance lead if the failure involves a regulated decision. The policy removes ambiguity about who has the authority to declare an incident resolved.

The final severity level assigned to an incident directly dictates the depth of the required post-mortem analysis. A SEV-1 incident mandates a formal, blameless post-mortem document with a rigorous root cause analysis and tracked remediation items within 5 business days. A SEV-3 might only require a lightweight retrospective note. This linkage ensures that the organization's learning and preventive investment are proportional to the incident's impact, creating a closed feedback loop from detection to systemic improvement.