Severity Levels for Third-Party Outages: A Scale That Holds Up

Most severity scales were written with an unstated assumption: that the team being paged can fix the thing that broke. The definitions reflect it. A SEV1 mobilises everyone because everyone is needed, and the escalation path exists to gather the people who can restore service.

A third-party outage removes the premise. Nobody on your team can fix the vendor, the restoration timeline belongs to someone who will not tell you what it is, and a full mobilisation gathers a room of people with nothing to do. Teams that route vendor incidents through an unmodified internal scale end up in one of two failure modes: they declare a SEV1, assemble a war room, and sit in it, which trains everyone to take the next one less seriously; or they undercall it because nobody can act, and the customer impact goes uncommunicated for an hour.

The fix is not a separate scale. It is a scale that keys on what your users are experiencing and carries a separate axis for what your team can do about it. This article gives that structure, shows how to wire it into routing, and covers the review that keeps the calls honest. It assumes you already have a response process; if you do not, start with the third-party outage runbook.

Severity should answer one question: how much of what your users came to do is currently impossible. The vendor's own headline does not answer that, which is why the classification has to be made on your side of the boundary.

The second axis is agency, and separating it from severity is what stops the war-room problem. A SEV1 you can fix and a SEV1 you can only wait out share a communication posture and share nothing else. Naming the difference in the declaration tells everyone which one they are in before they join a call.

The most expensive classification mistake is inheriting the vendor's severity. A provider declaring a major outage is describing its own blast radius across its whole customer base, which has no defined relationship to yours. A major outage on a component you never call is a SEV4 for you, and a modest degradation on the one API your checkout depends on can be a SEV1.

This is why component-level detail changes the economics of the whole process. Vendor-level tracking gives you one bit per provider and forces a human to work out relevance under time pressure. Component-level tracking with a dependency map lets the initial classification be close to right before anyone is awake, and it is the single biggest reduction in false pages available to most teams. The noise argument is in alert fatigue and smart routing.

Two adjustments are worth building in. Severity should be allowed to rise with duration: a degradation nobody would page for at ten minutes may deserve a page at two hours, because backlogs and timeouts compound. And it should account for concurrency, since two independent SEV3s affecting the same user journey can be a SEV2 in combination even though neither qualifies alone.

A severity scale that does not change what happens is documentation. Each level needs a routing rule, and the rules should differ enough that the classification carries real consequences.

Route SEV1 and SEV2 to the paging tool and SEV3 to a channel, then resist the pressure to page on SEV3. Most alert fatigue comes from a severity definition that says notify and a routing rule that pages anyway, and once on-call learns that a level pages regardless, the scale has stopped conveying information.

Scope the rules by component and region wherever the vendor publishes that detail. A rule that fires on any incident at a large cloud provider will fire constantly and be muted within a quarter. A rule scoped to the components and regions you actually use will fire a handful of times a year and get read every time. Maintenance windows deserve their own treatment: suppressing announced maintenance is correct, and suppressing it without recording it is how a maintenance-window failure becomes invisible.

Make declaration cheap and downgrading normal. On-call classifying under uncertainty will over-call if downgrading feels like admitting a mistake. State explicitly that severity is a working hypothesis and that adjusting it on better information is the process working.

Review severity calls as a set, once a quarter. The question is not whether each individual call was defensible at the time; it is whether the distribution looks right. A scale where almost everything is SEV2 has collapsed into one level with extra paperwork.

Look for the two systematic errors. Over-calling shows up as SEV1s that resolved with no customer impact and no action taken, and it usually means the trigger is vendor-level instead of component-level. Under-calling shows up as incidents where customer communication started long after users noticed, and it usually means the classifier had no dependency map and defaulted to caution in the wrong direction.

Feed the SEV4 log into vendor reviews. Incidents that never touched you are still data about a supplier's operational health, and a provider with a rising SEV4 count is drifting in a direction worth raising at renewal even though it has never caused you an outage. That record is also the evidence base for the reporting described in reliability reporting for executives.

Should a vendor outage use the same severity scale as an internal incident? Use one scale, keyed on user impact, with an explicit note about whether your team can act. A separate scale creates translation problems during handovers, and an unmodified internal scale assumes a fix path that does not exist for third-party failures.

Should we page on-call if we cannot fix it? Yes, when user impact justifies it. Somebody has to verify blast radius, activate fallbacks, and start customer communication, and all of that is real work. What changes is the composition of the response: fewer engineers, more communication, and no expectation of a technical fix.

How do we classify when the vendor has not confirmed anything? Classify on observed user impact and record the vendor as unconfirmed. Waiting for confirmation is how customers find out before you do, and vendors routinely publish well after their customers notice.

Does a vendor major outage always mean a high severity for us? No. It means a high severity for the vendor. If the affected component or region is not on a path your product uses, it can be the lowest level on your scale while remaining worth logging.

How many severity levels should we have? Four is enough for almost everyone. Fewer than three cannot distinguish page from notify from record; more than five produces boundary arguments during incidents, which is the worst possible time to be having them.