Incident Severity Levels

Imagine a hospital emergency room where every patient is immediately rushed to the operating theater—the person with a paper cut, the patient having a heart attack, and everyone in between. The result would be chaos: critical patients dying while resources are wasted on minor issues. Emergency medicine solved this with triage—a systematic approach to categorizing patients by urgency.

Incident management faces the same challenge. Without severity classification, organizations oscillate between two failure modes: treating everything as critical (leading to alert fatigue and responder burnout) or treating everything as routine (leading to catastrophic delays on real crises). Neither extreme serves customers or teams.

Severity levels provide the triage framework for incidents. They determine how quickly responders mobilize, who gets paged, how much customer communication occurs, and what level of organizational attention the incident receives. Get severity wrong, and you either under-respond to crises or over-respond to non-issues. Get it right, and your organization deploys exactly the right level of effort to each situation.

Severity levels exist to calibrate response. Every incident response action has costs: responders' time, interrupted sleep, stakeholder attention, and organizational overhead. Severity classification ensures these costs are proportional to incident impact.

The Purpose of Severity Levels

1. Response Calibration: Match organizational effort to incident significance
2. Clear Escalation Triggers: Know when to wake people up at 3 AM vs. address during business hours
3. Communication Expectations: Determine who needs to know and how urgently
4. Resource Allocation: Decide when to pull in SMEs vs. let primary on-call handle it
5. Priority Setting: When multiple incidents occur, severity guides which gets attention first
6. Historical Analysis: Enable meaningful incident trending and improvement prioritization
7. SLA Mapping: Align incident response with customer contract commitments

The Consequences of Misclassification

Under-Severity (calling SEV-2 when it's SEV-1):

• Delayed response extends customer impact
• Critical stakeholders not informed in time
• Miss opportunity for faster mitigation with more resources
• Post-incident questions: "Why wasn't this escalated sooner?"

Over-Severity (calling SEV-1 when it's SEV-3):

• Responder burnout from unnecessary escalations
• Desensitization to severe alerts (the boy who cried wolf)
• Lost productivity from over-response
• Stakeholder fatigue from false alarms
• Erosion of trust in severity classifications

Clear, unambiguous severity criteria prevent debates during incidents and ensure consistent classification across responders. Good criteria are:

• Objective: Based on measurable factors, not subjective judgment
• Observable: Can be determined quickly during triage
• Comprehensive: Cover the dimensions that matter to your business
• Mutually Exclusive: It's clear which level applies
• Stable: Definitions don't change frequently

Dimensions for Severity Classification

Most severity frameworks consider multiple dimensions of impact:

Example Severity Definitions

Here's a concrete severity framework for a typical B2B SaaS product:

SEV-1 (Critical) — Any of:

• Complete unavailability of the application for >10% of users
• Core transaction processing (payments, orders) completely broken
• Active security incident or confirmed data breach
• Regulatory compliance system unavailable during filing period
• Significant customer data loss or corruption
• Public-facing API completely unavailable

SEV-2 (High) — Any of:

• Major feature broken with no workaround for >5% of users
• Significant performance degradation (>5× normal latency)
• Core functionality impaired but partially working
• Security vulnerability requiring urgent patching
• Single major customer completely unable to use service
• Data processing delays exceeding SLA

SEV-3 (Medium) — Any of:

• Minor feature broken affecting some users
• Workaround exists but causes significant inconvenience
• Performance degradation (2-5× normal latency)
• Non-critical integration failure
• Single non-critical component unavailable
• Intermittent issues affecting subset of requests

SEV-4 (Low) — Any of:

• Cosmetic issues (UI misalignment, typos)
• Feature works but edge case fails
• Slowness within acceptable bounds
• Internal tooling issues with workarounds
• Documentation gaps identified
• Non-blocking friction in user experience

Each severity level should have explicit response expectations. These expectations create accountability and help responders understand what's required. Key dimensions include:

• Response Time: How quickly must responders engage?
• Communication Cadence: How often must updates be provided?
• Escalation Path: Who is notified and when?
• Resolution Target: What's the expected resolution time?
• Post-Incident Requirements: What follow-up is mandatory?

Incidents evolve. What starts as a minor issue may escalate into a critical outage; what looks catastrophic may turn out to be limited in scope. Severity should reflect current reality, not initial assessment.

When to Escalate Severity

Increase severity when:

• Impact is larger than initially assessed (more users affected)
• Problem is spreading to additional systems
• Resolution is taking longer than expected
• Root cause is deeper than initially thought
• Customer/business impact becomes clear
• Mitigation attempts are failing

When to De-escalate Severity

Decrease severity when:

• Impact is confirmed to be smaller than feared
• Workaround successfully reduces customer impact
• Mitigation stabilizes the situation (even if root cause isn't fixed)
• Issue is contained to specific subset of users/features
• Initial alarm was disproportionate to actual problem

The Severity Change Protocol

1. Announce the Change: Post in incident channel: "Escalating this to SEV-1. Error rate now at 15% and rising."

2. Communicate Rationale: Briefly explain why severity changed: "Impact larger than expected—affecting checkout, not just cart."

3. Trigger Appropriate Response: Escalation should automatically trigger additional notifications and resources.

4. Update External Communications: Status page should reflect new severity if it affects customer impact statement.

5. Adjust Expectations: New severity means new response expectations—remind responders of updated cadence.

Cultural Considerations

Make severity changes routine, not controversial:

• Encourage early escalation ("better safe than sorry")
• De-escalation is not failure—it's accurate assessment
• The person closest to the data should propose severity changes
• IC makes final severity decisions during incident
• Post-mortem reviews whether initial severity was accurate (for learning, not blame)

What happens when you have two SEV-1 incidents simultaneously? Or when a SEV-1 strikes while you're still resolving a SEV-2? Concurrent incidents require explicit prioritization beyond simple severity levels.

Priority vs. Severity

Severity describes impact; priority describes response order:

• Severity: How bad is this problem? (Fixed classification)
• Priority: What should we work on first? (Dynamic ordering)

Two SEV-1 incidents have equal severity but may have different priority based on factors like:

• Cash flow impact (payments outage vs. reporting system)
• Customer contract obligations (SLA penalties at stake)
• Duration (longer-running incident may need to yield to fresh crisis)
• Fix complexity (quick win vs. deep investigation)

Prioritization Factors

When facing concurrent incidents:

1. Revenue Impact: Which incident loses more money per minute?
2. Customer Scope: Which affects more users or higher-value customers?
3. Data Risk: Is data at risk in either incident? Data issues trump availability.
4. Regulatory: Are there compliance implications? Regulators > customers.
5. Resolution Proximity: Is one incident close to resolution? Quick win may be worth prioritizing.
6. Cascade Risk: Could one incident cause the other to get worse?

Resource Splitting Strategies

• Sequential: Focus entire team on highest priority incident until resolved or stabilized
• Parallel: Split team with dedicated IC and responders for each incident
• Hybrid: Primary team on highest priority; secondary on-call manages lower-priority

For resource-constrained teams, sequential is often better than fragmented parallel attention.

Severity frameworks only work if the organization agrees on them. Misaligned expectations—where engineers classify SEV-2 and executives expect SEV-1 response—create friction and erode trust. Building alignment requires explicit discussion and ongoing calibration.

Stakeholder Alignment Process

1. Define Together: Engineering, product, support, and executives should collaborate on severity definitions. Each group has different perspectives on impact.

2. Use Real Examples: Abstract criteria are ambiguous. Calibrate with: "Last month's payment outage—was that SEV-1 or SEV-2?" Concrete examples expose disagreements.

3. Document Rationale: Don't just document criteria; explain why each dimension matters and how it maps to business impact.

4. Train Consistently: Everyone who might declare or respond to incidents should receive severity training. Include realistic scenarios and practice classification.

5. Review Regularly: In post-mortems, evaluate whether severity was accurate. If consistently over/under-classified, refine criteria.

The Severity Calibration Meeting

Quarterly, bring stakeholders together to review severity accuracy:

Agenda:

1. Review incidents from past quarter by declared severity
2. For each SEV-1/SEV-2, assess: "Was this classification accurate? Would we classify it the same today?"
3. Identify patterns: "Too many SEV-1s?" "Under-classified issues?"
4. Propose criteria adjustments if needed
5. Discuss any edge cases where classification was debated

The goal isn't to blame responders but to calibrate the system. Classification disagreements reveal ambiguous criteria that need clarification.

Standard severity frameworks handle most incidents well, but some situations require special consideration. These edge cases test your framework's completeness.

Security Incidents

Security events often follow different severity logic:

• Active compromise or data breach = SEV-1 always, regardless of affected user count
• Vulnerability discovered (not exploited) = Severity based on exploitability and exposure
• Security incidents may require different response procedures (incident response team, forensics, legal involvement)
• Consider a separate security incident classification parallel to operational incidents

Data Incidents

Data problems—loss, corruption, exposure—often warrant higher severity than equivalent availability issues:

• Data loss is often irreversible; availability issues resolve when fixed
• Regulatory requirements (GDPR, HIPAA) mandate specific response timelines for data incidents
• Customer trust impact from data issues exceeds trust impact from downtime

The 'Unknown' Severity

Sometimes you don't have enough information to classify accurately. Rather than guess incorrectly:

1. Start High, Adjust Down: If uncertain, declare at higher severity and downgrade once you have data. This ensures adequate response.

2. Time-Box Uncertainty: "I'm declaring SEV-2 pending investigation. If impact is confirmed smaller in 15 minutes, we'll downgrade."

3. Log Uncertainty: Note in incident record that initial classification was uncertain. This helps post-mortem learning.

External Incidents

When the problem isn't yours (AWS outage, Stripe down):

• Still classify by customer impact, not by where the fault lies
• Track externally-caused incidents separately for dependency analysis
• Response options are limited, but communication remains critical
• Consider if you should have redundancy for that dependency (post-mortem topic)