Your fallback can amplify the failure it was meant to survive.
What happened
On 29 May 2026, an upstream API change altered how capacity failures were reported to Microsoft 365 workloads using Azure OpenAI. Multiple calling layers treated the new responses as transient and retried them immediately without sufficient backoff or jitter. Microsoft reported that one failed request could produce as many as 48 additional attempts.
The internal traffic overwhelmed a shared Azure OpenAI inference-routing and load-balancing layer. Customers experienced higher latency, timeouts, HTTP 5XX responses and intermittent failures between 09:39 and 17:05 UTC. Impact was stronger in parts of Europe and Australia East, and the same mechanism reappeared when the rollout reached Sweden Central.
The boundary
This was not an outage of every Azure service or every Azure OpenAI deployment. Individual impact varied by customer, resource, region and processing path. Microsoft isolated the large first-party workload, rolled back the change, and subsequently scheduled dedicated routing, stronger overload controls and retry policy improvements.
The point
Multi-region placement does not remove a shared routing layer, and retries are not resilience unless their total amplification is bounded and tested.
Read Microsoft’s post-incident review.
More incident dossiers
- Your spare zone needs room for your failure — Google Cloud
- A cloud told 495 customers: restore from your own backups — IDC Frontier (IDCF Cloud)
- Two gateways. One shared way to fail. — Microsoft Azure
- One suspended account cut off three clouds — Google Cloud / Railway
- Multi-AZ did not survive the region — AWS
- Cloudflare went down, too — Cloudflare
- Azure’s global front door closed — Microsoft Azure
- One empty DNS record reached across AWS — AWS
All cloud outage evidence → · Test your cloud exit readiness →