Incident Library
Applied filters Root causeConfiguration changeComponentDatabase replicationClear 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

Cases6 cases

6 to 6 of 6

  1. 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.

    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
    Component
    Contributing factor
    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.

Check your cluster for this

These 6 cases involve Database replication and Database. 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