Incident Library
Applied filters ComponentDatabase failover managerSymptomHigh error rateClear 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. 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 6 cases involve Database failover manager 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.

Open kubegap

By root cause6

Hardware failure1 case

Component
DatabaseDatabase failover manager
Contributing factor
Partial rollout
Organisation
Neon
  1. IL-0306 A Neon pageserver's EC2 instance failed without warning and Postgres databases of 0.4% of us-east-1 projects stalled
    Neon2024

Configuration change1 case

Component
Cloud block storageDatabaseDatabase failover manager
Contributing factor
Excessive blast radiusMonitoring blind spotNo staged rolloutUnsafe failure behaviour
Organisation
Microsoft Azure
  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

Cloud provider outage1 case

Component
In-memory cacheDatabase failover manager
Contributing factor
Monitoring blind spotSingle point of failure
Organisation
GitLab
  1. IL-0291 GitLab.com's redis-sidekiq Sentinel could not elect a primary after a GCP host error, so Sidekiq was down for 30 minutes
    GitLab2023

Capacity exhaustion1 case

Component
Cloud block storageDatabaseDatabase failover manager
Contributing factor
Unverified assumptionNo staged rollout
Organisation
GitLab
  1. IL-0321 GCP snapshots on all Patroni nodes stalled GitLab.com's primary PostgreSQL disk, Patroni failed over and 5xx spiked
    GitLab2021

DNS or network fault1 case

Component
Coordination and key-value storeDatabaseDatabase replicationDatabase failover managerNIC, cable and switch port link
Contributing factor
Automation amplificationHarmful manual actionNo headroom
Organisation
Cloudflare
  1. IL-0240 Cloudflare API requests failed and the dashboard slowed for hours after the authentication database lost its replicas
    Cloudflare2020

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