Incident Library
Applied filters FactorOverlapping failuresOrganisationMicrosoft AzureClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases2 cases

1 to 2 of 2

  1. 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
  2. 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
Check your cluster for this

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