Incident Library
Applied filters Root causeConfiguration changeFactorUnsafe failure behaviourClear 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. 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
  2. IL-0215 Twilio's billing Redis master lost all balances and went read-only, and auto-recharge charged customer cards repeatedly
    Twilio2013
    Symptoms

    At 2:39 AM PDT (9:39 UTC) on 18 July 2013, services that relied on the redis-master of Twilio's billing system began to fail because the load on its host had become extreme. At 2:42 AM PDT monitoring alerted the on-call engineers to a failure in the Redis cluster.

    Database overloadData lossWrites rejected
    Trigger

    At 1:35 AM PDT on 18 July a loss of network connectivity disconnected all billing redis-slaves from the redis-master at once, and all of them requested a full synchronization at the same time. On-call engineers then restarted the overloaded redis-master.

    Root cause
    Configuration change
    Component
    In-memory cacheDatabase replication
    Contributing factor
    Retry stormHarmful manual actionUnsafe failure behaviour
    Detection

    At 2:42 AM PDT monitoring alerted the on-call engineers to a failure in the Redis cluster. At 3:28 AM PDT the billing system monitoring reported the anomalous charges, and at 12:36 PM PDT monitoring detected the recurrence.

    Remediation
    • Restarted the redis-master to relieve the high load, which loaded a wrong configuration
    • Took the billing system offline to stop further credit card charges
    • Restored service to all suspended accounts
    • Restored the lost account balances from the independent double-bookkeeping record in the relational datastore
    • Took billing offline again after the recurrence and reactivated the newly suspended accounts
    • Refunded all erroneous credit card charges
    • Gave all affected accounts a credit of 10% of their last 30 days of spend
    • Replaced the original Redis cluster and corrected the redis-master configuration
    • Activated the billing system progressively for groups of customer accounts
    Action items
    • Disable Redis restarts on the redis-master and recover the master by pivoting a slave instead
    • Add fail-safes so the billing system neither suspends accounts nor charges cards when balances are missing or cannot be written
    • Validate the billing system against the double-bookkeeping databases in real time
    Lessons

    Losing the in-flight balances and the ability to write balances at the same time exposed a flaw in the auto-recharge system: it failed in a dangerous way, charging cards and suspending accounts instead of stopping.

    View case
Check your cluster for this

These 2 cases involve Cloud block storage and In-memory cache. 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 change2 cases

Component
Cloud block storage1In-memory cache1Database1Database replication1Database failover manager1
Contributing factor
Unsafe failure behaviour2Excessive blast radius1Harmful manual action1Monitoring blind spot1No staged rollout1Retry storm1
Organisation
Microsoft Azure1Twilio1
  1. 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
  2. IL-0215 Twilio's billing Redis master lost all balances and went read-only, and auto-recharge charged customer cards repeatedly
    Twilio2013