A Standard Severity Classification for Cloud Incidents

CloudDowntime Research · Reliability researchPublished April 20, 2026Updated June 30, 20267 min read

Ask three providers whether last week had a "major" outage and you'll get three answers shaped by three different severity vocabularies and disclosure cultures. To compare reliability across AWS, Azure, and Google Cloud, you need one scale, defined by measurable impact rather than provider language. This is that scale - and the classification that admits incidents to our corpus.

The five levels

Each level is defined by three measurable axes: scope (how much is affected), duration (how long), and SLA breach (whether a monthly target was missed).

LevelScopeDurationSLA breachCorpus?
SEV-1 CriticalMulti-region or global control plane> 1 hourMultiple servicesYes
SEV-2 MajorMulti-service or full region> 30 minLikelyYes
SEV-3 ModerateSingle service, one region> 30 minPossibleNo
SEV-4 MinorSingle service, partial< 30 minUnlikelyNo
SEV-5 NegligibleDegradation, no meaningful impactAnyNoNo

Why these thresholds

30 minutes is the duration floor for "major" because it exceeds the recovery time of a well-configured multi-AZ failover - below it, the incident is a test of your redundancy, not a provider outage that reaches customers. Multi-service or multi-region scope is the breadth floor because single-service, single-region events are contained by standard architecture. And SLA breach is tracked separately because it is the axis with financial consequences - it is where the credit gap lives.

Mapping provider language

Providers don't publish on this scale, so classification maps their narratives onto it:

  • AWS "service disruption" affecting multiple services in a region → SEV-2; anything touching us-east-1 global dependencies → SEV-1.
  • Azure incidents tagged at the top two of its internal severities, or touching global services (Entra ID, WAN) → SEV-1/2.
  • Google Cloud incidents affecting multiple products or a global layer (Service Control, GCLB) → SEV-1/2.

The mapping is a judgment, applied consistently and documented per incident - which is what makes the corpus comparable. Use SEV-2 as your own "major incident" bar and your post-mortems will line up with the industry benchmarks in the 2026 report.

Framework questions

Why do cloud incidents need a standard severity scale?

Each provider uses its own severity language and thresholds, so "a major AWS incident" and "a major Azure incident" are not comparable. A provider-neutral scale defined by measurable impact - scope, duration, and SLA breach - lets you compare reliability across providers and over time.

What makes an incident "major" in this framework?

SEV-2 or worse: multi-service or multi-region customer impact lasting over 30 minutes with provider acknowledgement. This is the threshold used to admit an incident into the CloudDowntime corpus.