Incident Library
Applied filters ComponentDatabaseFactorChange with a delayed effectClear 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

Cases12 cases

12 to 12 of 12

  1. IL-0241 A database shard could not elect a new primary, and the Stripe API failed most requests in two periods on one day
    Stripe2019
    Symptoms

    On 10 July 2019 the Stripe API failed a substantial majority of requests twice, from 16:35 to 17:02 UTC and from 21:14 to 22:47 UTC. In the first period automated monitoring detected within a minute that a database cluster had failed to elect a new primary.

    High error rateFailover failureWrites rejectedIntermittent timeoutsSustained high node CPU
    Trigger

    The primary node of a database cluster failed at 16:35 UTC while one shard had several stalled nodes. The second period was set off by rolling the election protocol back to the previous minor version at 20:42 UTC.

    Root cause
    Software defect
    Component
    DatabaseDatabase failover manager
    Contributing factor
    Change with a delayed effectMonitoring blind spotExcessive blast radiusHarmful manual actionUnverified assumptionOverlapping failures
    Detection

    Automated monitoring detected the failed election within a minute, and the team was alerted at 16:36 UTC. The second period was announced at 21:14 UTC by automated alerts that some shards in the cluster were unavailable.

    Remediation
    • Restarted all nodes of the database cluster, which forced a successful primary election
    • Updated the production configuration and restarted the database cluster's nodes
    • Ramped traffic back up, putting services for user-initiated API requests first
    Action items
    • Alert when nodes stop reporting their replication lag
    • Alert when a shard enters a state that could trigger the election fault
    • Work with the database maintainers on a fix for the underlying fault
    • Add circuit breaking on failed operations to particular database clusters
    • Use fault isolation to contain the impact of a single failed shard
    • Limit the resources used by clients that keep retrying failed requests
    • Add procedures and tooling that make rapid configuration changes during incident response safer
    View case
Check your cluster for this

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

Breaking change in an upgrade4 cases

Component
Database4Message broker2Database replication1Database failover manager1Serverless function platform1
Contributing factor
Change with a delayed effect4Retry storm2Automation amplification1Excessive blast radius1Unreviewed defaults1Ignored early signal1Unknown limit1Monitoring blind spot1Overlapping failures1Unrepresentative staging1
Organisation
CircleCI1Daily1DeNA1Mercari1
  1. IL-0572 About 10 million Pub/Sub messages backed up and Merpay accounting data was not written to Cloud Spanner for over a day
    Mercari2026
  2. IL-0569 After an MHA master failover, one of three MySQL replicas failed with a malformed binlog error and could not catch up
    DeNA2026
  3. IL-0314 Daily's newly upgraded Aurora MySQL database deadlocked on meeting-event queries and its call servers kept restarting
    Daily2023
  4. IL-0294 CircleCI Docker and machine jobs stalled for nearly 12 hours after a VM cleanup queue lost all its RabbitMQ consumers
    CircleCI2021

Certificate or credential expiry1 case

Component
DatabaseDatabase replication
Contributing factor
Unverified assumptionChange with a delayed effectMonitoring blind spotNo safeguard on destructive change
Organisation
LootLocker
  1. IL-0490 Records were missing from LootLocker's new MySQL database after a migration cutover and the service degraded for 3 hours
    LootLocker2026

Capacity exhaustion1 case

Component
DatabaseJobs and CronJobs
Contributing factor
Unreviewed defaultsChange with a delayed effect
Organisation
CyberAgent
  1. IL-0435 Error rates rose as Aurora MySQL killed connections and declined queries to avoid OOM while load metrics stayed flat
    CyberAgent2026

Faulty deployment3 cases

Component
Database3CI system1
Contributing factor
Change with a delayed effect3Unverified assumption1Excessive blast radius1Inefficient query1Monitoring blind spot1Overlapping failures1Unrepresentative staging1
Organisation
CircleCI1Replicate1STORES1
  1. IL-0552 CircleCI's archival database ran out of storage, slowing workflow and job starts and the display of workflows in the UI
    CircleCI2025
  2. IL-0571 STORES reservation returned bursts of 504 errors when a smart-list query held a database process for over 20 minutes
    STORES2024
  3. IL-0483 Replicate's website and API returned slow responses and HTTP 500s for two hours as PostgreSQL connections ran out
    Replicate2023

Operator error1 case

Component
PostgreSQL vacuumDatabase
Contributing factor
Unreviewed defaultsChange with a delayed effect
Organisation
Kanmu
  1. IL-0582 Jobs piled up in Kanmu's PostgreSQL-based qg job queue on Aurora as dequeue slowed and dead tuples kept growing
    Kanmu2024

Configuration change1 case

Component
DatabaseSecrets store
Contributing factor
Configuration not in codeUnreviewed defaultsChange with a delayed effect
Organisation
MIT Open Learning
  1. IL-0511 MIT xPro stopped responding after a configuration deploy as pgbouncer logins to RDS failed with 'wrong password type'
    MIT Open Learning2023

Software defect1 case

Component
DatabaseDatabase failover manager
Contributing factor
Unverified assumptionExcessive blast radiusChange with a delayed effectHarmful manual actionMonitoring blind spotOverlapping failures
Organisation
Stripe
  1. IL-0241 A database shard could not elect a new primary, and the Stripe API failed most requests in two periods on one day
    Stripe2019