Cases2 cases
1 to 2 of 2
IL-0235Azure OpenAI GPT-5.2 returned HTTP 400 in seven regions after a configuration update the model engine did not supportMicrosoft 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.
- 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
- Component
- Contributing factor
- 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
IL-0339Azure Front Door and Azure CDN users saw intermittent connection errors, timeouts and latency spikes for hoursMicrosoft Azure2024- Symptoms
From 11:45 UTC on 30 July 2024, a subset of customers got intermittent connection errors, timeouts and latency spikes when connecting to Microsoft services that use Azure Front Door (AFD) and Azure Content Delivery Network (CDN). The Azure Portal team saw the first service degradation at 11:47 UTC.
- Trigger
Around 11:45 UTC the Azure network DDoS protection service was disengaging after a routine DDoS mitigation and returning traffic to its default routing to AFD, but the routes at one site in Europe could not be updated because the network control plane could not reach that site during a local power outage.
- Root cause
- Component
- Contributing factor
- Detection
The Azure Portal team detected service degradation at 11:47 UTC and began to investigate. At 12:10 UTC network monitoring correlated the Portal incident to a network issue at one site in Europe, and networking engineers joined.
- Remediation
- Rerouted traffic under the standard congestion playbook, which removed most of the impact by 13:58 UTC
- Ordered the network control plane to reissue its commands to the misbehaving device, which could not be reached
- Removed the device that kept attracting traffic from the network and scanned the network for other issues
- Action items
- Add the missing configuration on network devices so a DDoS mitigation issue in one geography cannot spread to another
- Improve validation and monitoring in the Azure network to detect invalid configurations
- Improve monitoring for when the DDoS protection service is unreachable from the control plane but still serving traffic
These 2 cases involve CDN and edge network and Data center power and cooling. 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 cause1
Configuration change2 cases
- Component
- Contributing factor
- Organisation