Audit your AI failover map for hidden shared capacity
Treat multi-provider failover as correlated until you can prove the capacity, cloud, and region paths are independent.
Shared capacity is the hidden dependency
On September 3, 2026, ChatGPT, Claude, and Grok each had a confirmed outage on its service dashboard. Multi-provider failover trades cost and complexity for availability, but only if the providers are independent. If inference paths share a capacity pool, your effective availability is the availability of that pool, not the product of separate paths.
Provider dashboards are not dependency maps. They tell you a service is down, not why. Claude's September 3, 2026 disruption began near 6:23 a.m. Pacific and ended near 9:16 a.m. Pacific, reaching claude.ai, the Claude API, and Claude Code.
Grok was offline from about 6:30 a.m. Pacific on September 3, 2026 for roughly three and a half hours.
The overlap is the audit trigger: a close start time is not proof of a shared cause, but it is a testable lead. Record start and end times, affected surfaces, and stated causes in one table, then compare providers. Keep that table as the baseline for the dependency map.
Microsoft did not log an Azure service-health incident for the September 3, 2026 outage window and rejected the claim that Azure caused the outages.
Cloudflare's CTO said Cloudflare's network had no significant service disruption during the September 3, 2026 outage window.
Those denials do not prove independence. Put them in the same table as the observed failure.
The arithmetic changes when the dependency is common
Failover design assumes independent failure probabilities. If two paths share a power feed, cooling loop, cloud region, or network path, the shared component is the point of failure. When both paths depend on D, the shared component sets a floor on the joint failure probability: P(D), not P(A) × P(B).
Treat the shared component as a first-class dependency. Capacity arrangements can make that shared component large enough to matter. In May 2026, Anthropic secured the full output of SpaceX's Colossus 1 data center in Memphis, Tennessee.
The Colossus 1 arrangement was reported to give Anthropic more than 300 MW of capacity, upward of 220,000 Nvidia GPUs, and a monthly cost of about $1.25 billion through May 2029.
That scale is a concentration, not a failure. When your failover target depends on the same provider, the same cloud, or the same physical site, you have not added independence. You have added another exposure to the same risk.
Instrument the shared dependency before you instrument the fallback. Track it in the same dashboard as provider status, and alert when it and the provider fail together. A fallback that shares a dependency does not reduce the probability of a correlated outage.
The shared-capacity failover audit is a dependency map
Build the map from disclosed capacity and observed failure. Run it before the next correlated outage, not after, and keep it current after each provider incident.
Each item is testable quickly, because the audit needs to find the shared hop before it fails.
- Inventory every disclosed capacity contract and note the region, cloud, power source, and term.
- Map each provider's physical and cloud dependencies, including shared data centers, network paths, and upstream capacity.
- Verify a second-region or second-cloud path that does not reuse the disclosed dependency.
- Alert on correlated provider outages by comparing dashboard timestamps and incident notes across providers.
Inventory forces you to see the contract, the region, and the term before you call a provider independent. A contract that names a site is a dependency, not a backup.
Mapping turns provider documentation into a dependency graph. If providers share a cloud region, a network path, or a power source, mark that edge as shared.
Verification tests whether your fallback can survive the disclosed concentration. A path that reuses the same disclosed dependency is not a path; add an independent second-region or second-cloud path that does not.
Alerting gives you a signal when independence is broken. Correlated outages are visible in timestamps and incident notes before a common cause is admitted.
If you cannot produce the map, treat the failover as correlated. If you can, instrument the shared hops and alert on the overlap.