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

Cases3 cases

1 to 3 of 3

  1. IL-0407 Azure OpenAI returned 5xx errors in 14 of 28 regions after an automated cleanup deleted its GPU VMs and endpoints
    Microsoft 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.

    High error rateResources deleted
    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
    Configuration change
    Component
    Model inference serverAutomated capacity manager
    Contributing factor
    No staged rolloutNo safeguard on destructive changeUnverified assumption
    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.

    View case
  2. IL-0533 Names in chinacloudapp.cn and chinacloudsites.cn stopped resolving as DNS caches expired, breaking Azure China services
    Microsoft 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.

    DNS resolution failuresHigh error rateMonitoring outage
    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
    Configuration change
    Component
    Authoritative DNS servers and records
    Contributing factor
    Unverified assumptionCache-masked failure
    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
    View case
  3. IL-0225 An IGP purge command made every Microsoft WAN router recompute routes, causing global latency, timeouts and packet loss
    Microsoft Azure2023
    Symptoms

    From 07:08 UTC on 25 January 2023, customers saw long network latency and timeouts when connecting to resources in Azure regions and to other Microsoft services such as Microsoft 365 and Power Platform. Microsoft's monitoring detected DNS and WAN issues from 07:11 UTC.

    High latencyIntermittent timeoutsIntermittent connection failuresPacket lossNetwork unreachable
    Trigger

    A network engineer adding capacity to the global WAN in Madrid ran a step of a recently changed standard operating procedure that purged the IGP database; on the router manufacturer involved, that command runs on all IGP-joined routers instead of only the local one.

    Root cause
    Configuration change
    Component
    Backbone network (WAN)Interior routing (IGP)BGP routing
    Contributing factor
    No configuration testsUnverified assumptionExcessive blast radiusHarmful manual action
    Detection

    Monitoring detected DNS and WAN issues from 07:11 UTC and alerted the on-call engineers within 5 minutes of the command being run. The team reviewed all recent changes and identified the command by 08:20 UTC. The engineer making the change was not informed of the alerts because of the unqualified changes to the SOP.

    Remediation
    • Restarted by hand the paused WAN health and traffic engineering systems, which ended the remaining packet loss
    Action items
    • Audit and block similar widespread-impact commands across all three vendors for all WAN router roles
    • Give on-call engineers real-time visibility of approved and unqualified activity on network devices
    • Run regular mandatory operational training and attestation of following all SOPs
    • Have the Change Advisory Board review all SOPs still pending qualification within 30 days
    View case
Check your cluster for this

These 3 cases involve Backbone network (WAN) and BGP routing. 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.

Open kubegap

By root cause1

Configuration change3 cases

Component
Backbone network (WAN)1BGP routing1Automated capacity manager1Authoritative DNS servers and records1Interior routing (IGP)1Model inference server1
Contributing factor
Unverified assumption3Excessive blast radius1Cache-masked failure1Harmful manual action1No configuration tests1No safeguard on destructive change1No staged rollout1
Organisation
Microsoft Azure3
  1. IL-0407 Azure OpenAI returned 5xx errors in 14 of 28 regions after an automated cleanup deleted its GPU VMs and endpoints
    Microsoft Azure2024
  2. IL-0533 Names in chinacloudapp.cn and chinacloudsites.cn stopped resolving as DNS caches expired, breaking Azure China services
    Microsoft Azure2024
  3. IL-0225 An IGP purge command made every Microsoft WAN router recompute routes, causing global latency, timeouts and packet loss
    Microsoft Azure2023