阅读中文版本

Incident Severity Classification Workflow

Assign a severity from user impact and scope so response effort and escalation match the actual harm.

Overview

Classify incidents consistently by impact so the right people and cadence are engaged.

This workflow is reusable across teams and environments; adapt the commands to your tooling while keeping the sequence and checkpoints intact.

Environment and prerequisites

• An incident management tool
• Defined severity levels
• An on-call roster

Procedure

1. Determine user impact

Assess how many users are affected and whether core functions are blocked.

Expected state: A clear impact statement exists.

2. Assess scope and duration

Estimate the blast radius and how long the condition has persisted.

Expected state: Scope and duration inform urgency.

3. Assign a severity level

Map impact and scope to the defined severity scale and record the rationale.

Expected state: A severity with justification is recorded.

4. Escalate accordingly

Page the roles the severity requires and set the communication cadence.

Expected state: Response effort matches the severity.

# example severity mapping
# SEV1: core function down for all users
# SEV2: degraded for many users
# SEV3: minor impact with workaround

Verification

Confirm the recorded severity matches the impact assessment and that escalation followed the severity policy.

Decision points

When impact is unclear early?

• Start high and downgrade
• Start low and upgrade

Recommendation: Start high and downgrade once data is clear, to avoid slow response to real outages.

Who sets severity?

• Incident commander
• Anyone on call

Recommendation: The incident commander owns the final level; anyone can propose a change.

Common failures

• Under-classifying delays the right responders.
• Over-classifying burns out on-call for minor issues.
• Static severity ignores an evolving outage.