Cases2 cases

1 to 2 of 2

1. IL-0248 Azure OpenAI inference requests slowed and failed in several regions as a retry storm overloaded the routing layer

   Microsoft 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.

   High latencyHigh error rateIntermittent timeoutsOOMKilled

   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

   Faulty deployment

   Component

   Model request routing

   Contributing factor

   Retry stormExcessive blast radiusUnverified assumption

   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.

   View case
2. IL-0235 Azure OpenAI GPT-5.2 returned HTTP 400 in seven regions after a configuration update the model engine did not support

   Microsoft Azure2026

   Symptoms

   From 23:20 UTC on 9 March 2026 Azure OpenAI Service customers received HTTP 400 and HTTP 429 error responses for the GPT-5.2 model in Australia East, Central US, East US 2, Korea Central, Norway East, Sweden Central and UK South. All other GPT models kept working.

   High error rateLoad imbalance

   Trigger

   An update to the Azure OpenAI GPT-5.2 model enabled feature settings meant to improve service efficiency and resilience. The model engine version running in production did not yet support those settings. The update was rolled out to the whole fleet in stages under Safe Deployment Practices.

   Root cause

   Configuration change

   Component

   Model inference serverModel request routing

   Contributing factor

   Unrepresentative stagingMonitoring blind spotOverlapping failures

   Detection

   Service monitoring detected the issue at 00:19 UTC on 10 March, about an hour after impact began. Detection was late because monitoring was set up for client-side HTTP 400 errors and not for service-side anomalies.

   Remediation

   • Rolled back the GPT-5.2 configuration in all affected regions instead of waiting for a hotfix
   • Completed the routing updates and restored full regional capacity information so traffic was spread normally again

   Action items

   • Train engineers on the operating procedures, including which scenarios can be rolled back quickly
   • Store a cached known-good version of the traffic routing details for when the capacity service cannot provide current data
   • Set thresholds for service-side HTTP 400 errors in monitoring
   • Improve anomaly detection on HTTP 4xx errors to alert on unusual error rates below the usual thresholds
   • Add signals to the deployment systems so problematic rollouts stop automatically
   • Make sure early rollout stages have enough backend model instances to catch such problems

   View case

By root cause2