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

Cases3 cases

1 to 3 of 3

  1. IL-0339 Azure Front Door and Azure CDN users saw intermittent connection errors, timeouts and latency spikes for hours
    Microsoft 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.

    Intermittent connection failuresIntermittent timeoutsHigh latencyPacket loss
    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
    Configuration change
    Component
    CDN and edge networkDDoS protection serviceNetwork control plane (SDN)Data center power and cooling
    Contributing factor
    Overlapping failuresExcessive blast radiusMonitoring blind spot
    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
    View case
  2. IL-0367 Azure Storage in Central US rejected VM disk I/O, taking down VMs and the SQL Database and Cosmos DB services on them
    Microsoft Azure2024
    Symptoms

    From 21:40 UTC on 18 July 2024, virtual machines in the Azure Central US region lost access to their disks, and the services running on those VMs failed. Azure SQL Database and SQL Managed Instance showed unhealthy nodes and login failures, Cosmos DB requests failed, and service management operations failed across many Azure services.

    Storage disconnected or stale mountsService outageHigh error rateFailover failureStale endpoint routing
    Trigger

    Routine changes to the VM host fleet led to a new allow list of VM host address ranges being generated and published to all Storage scale units in Central US. Recent network configuration changes had made some of the infrastructure file servers that hold the source data unreachable from the server generating the list, so the published list was incomplete.

    Root cause
    Configuration change
    Component
    Cloud block storageDatabaseDatabase failover manager
    Contributing factor
    Unsafe failure behaviourNo staged rolloutExcessive blast radiusMonitoring blind spot
    Detection

    Service monitoring detected the drop in VM availability at 22:06 UTC while the allow list update was being published. SQL monitoring detected unhealthy nodes and login failures within one minute of SQL becoming unavailable, and monitoring flagged the availability drop for Cosmos DB, SQL DB and SQL DB Managed Instance at 22:14 UTC.

    Remediation
    • Halted the allow list update workflow worldwide
    • Paused all deployments in the Central US region
    • Paused compute buildout deployments in all regions
    • Updated the configuration of all Storage scale units in Central US, restoring storage availability by 02:55 UTC
    • Started geo-failovers for SQL databases with automatic failover policies
    • Restarted SQL gateway nodes to refresh their caches and route connections to the right nodes
    • Forced completion of SQL failovers that had not completed
    • Failed over the Cosmos DB control plane and active-passive accounts with a write region in Central US
    • Cancelled customer-triggered graceful switch region operations that blocked Cosmos DB failovers
    • Removed locks on Cosmos DB service metadata to force-complete stuck failovers
    • Repaired impacted Cosmos DB partitions for single-region accounts
    • Repaired backend nodes and failed Cosmos DB accounts back to Central US, redoing failback where it failed
    Action items
    • Make the allow list generation workflow detect incomplete source information and halt
    • Alert on storage requests rejected by allow list checks
    • Deploy allow lists one Availability Zone and storage type at a time, over 24 hours
    • Add VM health checks and an automatic stop to the allow list deployment workflow
    • Reevaluate the policy for Microsoft-managed failover of SQL failover groups
    • Fix the Cosmos DB failback workflow that broke some MongoDB drivers for MongoDB API accounts
    • Fix Cosmos DB failback for accounts with private endpoints so it does not need redoing
    • Make the storage data-plane firewall reject invalid allow lists and keep the last-known-good state
    • Improve Azure NetApp Files monitors so impacting events are detected and classified in time
    • Monitor more Azure NetApp Files service metrics to correlate similar events faster
    • Make the SQL Service Fabric cluster location change notifications reliable under load
    • Make SQL geo-failover workflows more robust so they complete
    • Remove the issues that delayed 5% of Cosmos DB failovers
    • Migrate Azure DevOps customer metadata to the right geography
    • Decouple Azure NetApp Files regional reads and writes to keep this class of issue to one region
    • Evaluate caching to reduce Azure NetApp Files reliance on stored utilization data
    • Add automatic per-partition failover for Cosmos DB multi-region active-passive accounts
    • Build the Resilient Ephemeral OS disk improvement so VMs survive storage incidents better
    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 routing1Cloud block storage1CDN and edge network1Database1Data center power and cooling1DDoS protection service1Database failover manager1Interior routing (IGP)1Network control plane (SDN)1
Contributing factor
Excessive blast radius3Monitoring blind spot2Unverified assumption1Harmful manual action1No configuration tests1No staged rollout1Overlapping failures1Unsafe failure behaviour1
Organisation
Microsoft Azure3
  1. IL-0339 Azure Front Door and Azure CDN users saw intermittent connection errors, timeouts and latency spikes for hours
    Microsoft Azure2024
  2. IL-0367 Azure Storage in Central US rejected VM disk I/O, taking down VMs and the SQL Database and Cosmos DB services on them
    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