Reliability and observability

Incident severity

Also known as Incident priority, Severity level

By WeavePublished 1 min read

Definition

Incident severity is a classification of the impact, urgency, and scope of a service incident. A severity level guides response priorities and communication; it is not a measure of personal fault.

Classify impact, not blame

Severity should help responders make a quick decision. Criteria may include how many users are affected, whether a critical workflow is unavailable, how long the impact is expected to last, and whether data or security is at risk.

The labels themselves vary by organization. One team may use Sev 1 for a broad outage and Sev 3 for a limited degradation. The label matters less than the written criteria, response expectations, and escalation path attached to it.

Make the policy usable

Keep the severity matrix short enough to use under pressure. Include who is paged, who communicates with stakeholders, what response target applies, and how the level can change as evidence develops. A first estimate can be revised without treating the revision as a failure.

Use severity after recovery

Review whether the classification matched actual impact and whether the response process worked. Compare incidents by service and failure mode, with care around changes in traffic and monitoring. Severity is a useful grouping variable, but it should not replace measures of user impact or recovery time.

Weave can help connect incident reviews to pull request and delivery history so teams can investigate contributing patterns with more context.

How this relates to Weave

Weave helps teams study the engineering changes and review patterns that surround incidents. Severity and customer impact should come from the incident management system, while Weave provides context for the work that preceded and followed the event.

Explore Engineering intelligence

Sources and further reading

  1. Incident Management Guide, Google SRE