Graph
Cases3 cases
1 to 3 of 3
IL-0248Azure OpenAI inference requests slowed and failed in several regions as a retry storm overloaded the routing layerMicrosoft Azure2026- Symptoms
From 09:39 to 17:05 UTC on 29 May 2026, customers sending inference requests to Azure OpenAI Service saw higher latency, intermittent failures, timeouts and HTTP 5XX errors. Automated monitoring detected falling request success rates at 09:39 UTC, and regions in Europe and Australia East, which processed the most affected traffic, were hit hardest.
- Trigger
A change in an upstream API layer used by Microsoft 365 made some capacity-related failures surface as transient server failures that callers retry. It rolled out first in Australia East and later in Sweden Central.
- Root cause
- Component
- Contributing factor
- Detection
Automated monitoring detected a drop in request success rates at 09:39 UTC and started the incident investigation.
- Remediation
- Isolated the internal workload that sent the amplified retries onto dedicated infrastructure
- Rolled back the triggering change in the upstream service and reduced retry-driven traffic
- Cleared the backlogged requests
- Action items
- Move large first-party generative AI workloads onto dedicated routing infrastructure instead of the shared inference load balancing stamp
- Improve diagnostic guidance, runbooks and alerting to tell secondary crash symptoms from the real source of overload
- Work with upstream teams on retry policy design, dependency contracts and telemetry to catch retry amplification early
- Add stronger overload prevention and throttling so no single internal workload can overwhelm shared components
- Find and remove single points of failure in the inference routing layer
- Lessons
Internal workloads were not protected the way external traffic was: their traffic skipped some rate limiting and overload controls, so the amplified retries reached shared infrastructure. The apparent recovery after disabling the suspected feature hid the real cause until the problem came back at larger scale in Sweden Central.
IL-0407Azure OpenAI returned 5xx errors in 14 of 28 regions after an automated cleanup deleted its GPU VMs and endpointsMicrosoft Azure2024- Symptoms
From 00:00 UTC on 13 July 2024 a subset of Azure OpenAI (AOAI) customers got errors, such as 5xx responses, when calling their Azure OpenAI endpoints in 14 of the 28 regions that offer the service. Service monitoring saw failure rates cross their thresholds at 00:05 and alerted engineers.
- Trigger
A change to the global configuration file of the Azure OpenAI resource automation removed 14 resource groups that were thought to be unused, and the automation then deleted every resource in them.
- Root cause
- Component
- Contributing factor
- Detection
Service monitoring detected failure rates above the defined thresholds at 00:05 UTC and alerted engineers, five minutes after impact began.
- Remediation
- Stopped the automation that was running the cleanup
- Added resource locks and blocked delete requests at the ARM and Automation levels
- Recreated the deleted resources, rebuilding the service in parallel across the 14 regions
- Manually reconfigured Azure Redis and Private Link for GPT-4o with the Azure Redis and Azure Networking teams
- Manually restored DALL-E, adding the managed identity between its frontend and backend to an allowlist
- Turned the automation back on on 15 July, which restored fine-tuning deployments
- Action items
- Make the configuration policy regional and follow Safe Deployment Practices for all later configuration updates
- Remove incorrect metadata tags on resources the automation must not manage and exclude them in the automation configuration
- Concentrate the regional makeup of workloads in fewer regions
- Improve the automation that engages incident response personnel
- Investigate additional change management controls so that all production changes go through a gated safe deployment process (estimated completion August 2024)
- Update the communications tooling with Azure OpenAI data so affected customers can be scoped and notified faster
- Investigate additional test coverage and verification procedures to de-risk future configuration updates (estimated completion September 2024)
- Add active monitoring for each model family that does not depend on customer traffic
- Build out model pools with more parallelism to shorten recovery
- Lessons
Microsoft names the missing safe deployment step as the main gap in its change management: a configuration change delivered as a global content update could not be rolled out region by region, so a single change caused a multi-region incident. Resource groups that mixed resources the automation managed with resources it did not know had let the automation's configuration drift from what actually existed in the production subscription.
IL-0533Names in chinacloudapp.cn and chinacloudsites.cn stopped resolving as DNS caches expired, breaking Azure China servicesMicrosoft Azure2024- Symptoms
From 03:45 CST on 23 April 2024, FQDNs in two system domains of Azure in China, chinacloudapp.cn and chinacloudsites.cn, gradually stopped resolving, and customers in the Azure China regions had trouble connecting to many Azure services and managing resources. Internal monitors alerted engineers to the degradation at 04:37 CST.
- Trigger
At 03:45 CST a configuration change made through a domain registrar, as a step of a domain decommissioning workflow, updated the nameservers of chinacloudapp.cn and chinacloudsites.cn to a set of inactive servers.
- Root cause
- Component
- Contributing factor
- Detection
Internal monitors alerted engineers to the degradation in the Azure China Cloud at 04:37 CST and created an incident, which the engineering team acknowledged at 04:39 CST.
- Remediation
- Reverted the two domains to their previous working nameservers
- Action items
- Suspended further runs of the domain lifecycle process until the management tool covers Azure in China
- Make the validation process of domain lifecycle management include signals from all cloud regions
- Add validations that get nameserver information by resolving the zone directly over the Internet
These 3 cases involve Automated capacity manager and Authoritative DNS servers and records. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.
By root cause2
Faulty deployment1 case
- Component
- Contributing factor
- Organisation
Configuration change2 cases
- Contributing factor
- Organisation