Incident Library
Applied filters Root causeOperator errorSymptomService outageFactorHarmful manual actionClear 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

Cases3 cases

1 to 3 of 3

  1. IL-0242 Both PostgreSQL servers behind matrix.org were lost during a disk expansion, and the homeserver was down for 24 hours
    Matrix.org Foundation2025
    Symptoms

    On 2 September 2025 the matrix.org homeserver went down at 17:45 UTC and stayed down until 18:00 UTC the next day. Both machines of its PostgreSQL cluster were out of action: the original primary had lost its RAID array during a disk expansion, and the data directory of the new primary had been deleted by mistake.

    Service outageData loss
    Trigger

    During maintenance to add drives, an existing drive disappeared from the primary database server's RAID 10 array at 11:17 UTC, which led to a failover and a rebuild of that server. The outage itself began when the data directory of the new primary on db-01 was deleted while clearing a failed restore on db-02.

    Root cause
    Operator error
    Component
    DatabaseDatabase backups and snapshotsDatabase replication
    Contributing factor
    Overlapping failuresHarmful manual actionUnpatched known bugNo safeguard on destructive change
    Detection

    Monitoring fired when the drive disappeared from db-02's RAID array at 11:17 UTC, and Mythic Beasts confirmed the issue. The team realised it had deleted db-01's data directory, and the backend team was then paged, an incident was opened and an emergency was declared.

    Remediation
    • Created a fresh RAID 10 array on db-02
    • Unblocked WAL archiving from the new primary on db-01 to S3
    • Started restoring db-02 from the S3 backups with wal-g
    • Shut down Synapse and the damaged primary database
    • Remounted the data partition of db-01 read-only
    • Copied the WALs missing from S3 from db-01 to db-02
    • Updated wal-g and patched it to continue from the partial restore
    • Configured a restore_command wrapper that fetched WALs from S3 and the local files, and replayed them in standby mode
    • Promoted db-02 to primary and restarted Synapse
    • Ran backups against the primary while no replica existed
    • Rebuilt db-01 as a replica from a base backup of db-02
    Action items
    • Run pg_repack to reclaim free space
    • Take incremental backups more often, since they restore faster than WAL replay
    • Reduce Synapse's storage requirements
    • Consider changing the terminal background colour by the database's role, for example by watching for the standby.signal file
    • Consider wrapper scripts around sensitive commands, such as an alias for rm, and automating operations such as starting a base backup from primary to secondary
    • Shorten the recovery time, with infrastructure from service providers
    • Upgrade wal-g on all servers and repeat disaster recovery testing with it
    • Explore ZFS local snapshots at the next hardware refresh
    • Make status.matrix.org the source of truth during incidents and keep social media updated
    Lessons

    Most of the difficulty came from the size of the database: restoring 51TB and replaying WALs took far longer than hoped, and incremental backups restore much faster than WAL replay. Running a destructive command on the wrong server was the turning point, and Matrix.org looks for better tooling and processes rather than blaming the individual; working as a trio did not catch the mistake, and server names that suggest a role caused confusion because a primary and a secondary swap roles. The recovery lost no data, but the recovery time needs to be shorter, and the wal-g versions on the disaster recovery server and the production servers had drifted apart.

    View case
  2. IL-0332 A test run against the production database truncated every table and travis-ci.com was down for about 5.5 hours
    Travis CI2018
    Symptoms

    On 13 March 2018 at 12:14 UTC every table in travis-ci.com's production PostgreSQL database was truncated. Alerts fired right away, and customers reported missing account data; people who signed in saw blank user profiles.

    Data lossService outage
    Trigger

    At 12:04 UTC a developer ran a test suite in an old tmux shell that still had a DATABASEURL environment variable pointing at the production database, and the Database Cleaner gem sent a truncate query to it. The query was blocked for about 10 minutes and executed at 12:14 UTC.

    Root cause
    Operator error
    Component
    Database
    Contributing factor
    No safeguard on destructive changeHarmful manual action
    Detection

    Alerts fired immediately after the truncation, and customers reported missing account data.

    Remediation
    • Took all applications offline
    • Provisioned a replacement database from a snapshot taken that morning
    • Reattached the restored database and brought platform services back up
    • Worked through the backlog of builds until it cleared
    • Revoked all affected login tokens by 14:22 UTC on 14 March
    • Contacted affected customers and advised them to rotate stored credentials and check build logs
    Action items
    • Revoke the truncate permission on the databases
    • Make the internal spechelpers check for the DATABASEURL environment variable
    • Make the developer shell prompt warn when a DATABASE_URL is set
    • Submit a pull request to the Database Cleaner gem guarding against a remote DATABASE_URL
    • Create an alias for the follower database so it is easy to connect to for work against production data
    • Automate database failover and maintenance to cut manual recovery steps
    Lessons

    Developers connected to the production primary with write access because the tooling made the read-only follower hard to reach. While responding, Travis CI left user-facing applications running, which created duplicate user ids, and did not turn some alerts back on, which hid the stopped cron scheduler. Even the most experienced developers can make an inadvertent mistake that causes a large outage. The whole production database was recovered with only about 15 minutes of data loss.

    View case
  3. IL-0506 UC Berkeley DataHub logins failed and students got empty home directories after the JupyterHub database was overwritten
    UC Berkeley2017
    Symptoms

    At about 1 AM on 9 February 2017, UC Berkeley's DataHub was reported down: users trying to log in got a proxy error. The hub pod was running, but its log was full of sqlite errors.

    Service outageData lossMisrouted requests
    Trigger

    While debugging, an operator ran `.save jupyterhub.sqlite` in sqlite3 inside the hub pod without having attached the database, which replaced the JupyterHub database file with an empty one.

    Root cause
    Operator error
    Component
    DatabasePersistent volumes and stateful setsJupyterHub
    Contributing factor
    No safeguard on destructive changeUnsafe failure behaviourHarmful manual action
    Detection

    DataHub was reported down at about 1 AM, when users got a proxy error at login. At 1:12 AM a user reported that he could log in but all his notebooks were gone.

    Remediation
    • Scaled the hub to 0 replicas
    • Rebuilt the JupyterHub sqlite database by matching Kubernetes PVC names back to user ids
    • Set cookie_id to null instead of a dummy value and attached the rebuilt database to the hub
    • Changed the cookie secret in the hub pod and restarted it to log all users out
    • Deleted all user pods to log everyone out
    • Ran a script that filled in cookie_id for all users, restarted the hub and deleted all user pods again
    • Dropped the new users with a '.' in their name and renamed the older users from '-' to '.'
    Action items
    • Report upstream that JupyterHub uses only part of the cookie secret and discards the rest
    • Report upstream that the cookie_id column of the users table should have UNIQUE and NOT NULL constraints
    • Ask KubeSpawner to support username hashes in PVC and pod names so the names stay the same when the database is deleted
    • Ask OAuthenticator to support using the id from the Google authenticator as the user id, giving stable user ids
    • Switch to Google Cloud SQL, a hosted and managed MySQL database
    • Take regular and tested backups of the database
    • Start an operational FAQ of things to do and not to do
    • Set up better monitoring and paging
    • Document escalation procedures explicitly
    View case
Check your cluster for this

These 3 cases involve Database and Database backups and snapshots. 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

Operator error3 cases

Component
Database3Database backups and snapshots1Database replication1JupyterHub1Persistent volumes and stateful sets1
Contributing factor
Harmful manual action3No safeguard on destructive change3Unpatched known bug1Overlapping failures1Unsafe failure behaviour1
Organisation
Matrix.org Foundation1Travis CI1UC Berkeley1
  1. IL-0242 Both PostgreSQL servers behind matrix.org were lost during a disk expansion, and the homeserver was down for 24 hours
    Matrix.org Foundation2025
  2. IL-0332 A test run against the production database truncated every table and travis-ci.com was down for about 5.5 hours
    Travis CI2018
  3. IL-0506 UC Berkeley DataHub logins failed and students got empty home directories after the JupyterHub database was overwritten
    UC Berkeley2017