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

Cases2 cases

1 to 2 of 2

  1. Symptoms

    From 10:03 UTC on 29 September 2026, requests to Azure OpenAI Service, Foundry Agent Service, Foundry Models and Azure AI services in Sweden Central failed intermittently, took longer, or returned HTTP 500 and 503 errors. At 10:17 UTC service monitoring raised an alert on elevated failure rates for Azure OpenAI Service requests in the region.

    Trigger

    At about 09:38 UTC a planned deployment of an internal service in Sweden Central cleared that service's caches during the region's peak traffic hours.

    Root cause
    Component
    Contributing factor
    Detection

    Service monitoring detected elevated failure rates for Azure OpenAI Service requests in the region at 10:17 UTC and alerted the engineering teams; engineers were engaged at 10:28 UTC.

    Remediation
    • reconfigured the backend service's automated health check so it no longer depended on remote connectivity, which stopped the restart loop
    Action items
    • Reconfigure the backend service's automated health check so it no longer depends on connectivity to its database layer
    • Add monitoring and alerting on the load and latency of the caching layer used by the backend service
    • Update troubleshooting and procedural guidance for connection exhaustion scenarios for on-call engineers
    • Add throttling and rate limiting to protect the backend service from sudden traffic increases (estimated October 2026)
    • Increase the resource capacity of the caching layer used by the backend service across regions (estimated October 2026)
    • Improve diagnostic metrics and automated detection to identify such issues more quickly (estimated October 2026)
    • Partition the caching layer used by the backend service to increase its throughput (estimated December 2026)
    Lessons

    A health check that depends on a remote dependency turns a dependency problem into a restart loop: instances that cannot reach the database are killed, the remaining ones take more load and retries, and adding instances or resources does not help until the check itself is changed. Clearing a cache during peak traffic can multiply load on the backend behind it, especially when cache-read defects let lookups bypass the cache. Connection exhaustion was hard to see because the existing network and diagnostic metrics did not show it.

  2. Symptoms

    From about 10:30 UTC on 30 August 2023, customers had trouble accessing or using Azure, Microsoft 365 and Power Platform services in Australia East. The affected Azure services included Azure Kubernetes Service (AKS) along with storage, SQL Database, Cosmos DB, virtual machines and Azure Resource Manager.

    Trigger

    At 08:41 UTC a lightning strike on electrical infrastructure about 18 miles away caused a utility voltage sag that shut down the cooling chillers of datacenters in one Australia East availability zone; 13 chillers failed to restart automatically and five could not be restarted, so two data halls overheated and their infrastructure was shut down.

    Root cause
    Component
    Contributing factor
    Detection

    Cosmos DB impact was detected by monitoring at 10:47 UTC, first automated communications went to Azure Service Health at 10:48 UTC, the public Azure Status page was updated at 11:30 UTC, and all subscriptions in Australia East were sent portal communications at 11:36 UTC.

    Remediation
    • shut down the remaining networking, compute and storage in the two affected data halls so the chilled water loop could cool down
    • restarted the five chillers manually at 12:12 UTC
    • restored power to all hardware by 15:10 UTC and brought infrastructure back in phases
    • restored AKS operations through the recovery of the SQL Database operation queue, with no other mitigation
    Action items
    • AKS: convert all operation queue SQL Database databases to be zone redundant (estimated September 2023)
    • AKS: replace all cross-region SQL Database queue usage with zone-redundant Service Bus queues (estimated September 2023)
    • Change the control timing logic of the Chiller Management System so chillers do not fail to restart after voltage fluctuations
    • Change the emergency procedure for manual restarts of simultaneous chiller failures from an adjacent sequence to a load-based sequence per data hall
    • Increase technician staffing at the datacenter as a temporary measure for manual chiller restarts
    • Storage: optimise the large-scale recovery process and update troubleshooting guides (estimated December 2023)
    • Azure Service Fabric: improve reliability of SQL Database tenant ring recovery (estimated December 2023)
    • SQL Database: review the trigger criteria of auto-failover groups (estimated October 2023)
    • SQL Database: upgrade internal tooling to enable mass migration of databases (estimated December 2023)
    • Cosmos DB: optimise Service Managed Failover for single-region-write accounts (estimated November 2023)
    • ARM: complete the migration of its storage layer to the zonally redundant architecture (estimated December 2023)
    • Incident management: harden readiness, process and playbook for power-down scenarios (estimated October 2023)
    Lessons

    A control plane spread across availability zones still fails with a zone when one of its dependencies, here the SQL Database operation queue, is not zone redundant. When a second region uses the same database, the failure crosses into that region as well. Workloads already running were not expected to be affected; what stopped was everything that needs the managed service's control plane, such as scaling and cluster changes.

Check your cluster for this

These 2 cases involve Application database and AKS control plane. 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