Cases17 cases

1 to 5 of 17

1. IL-0309 Preset's RDS PostgreSQL 14.7 to 17.9 upgrade in US East 1 ran out of storage and took Superset down for six hours

   Preset2026

   Symptoms

   A planned major version upgrade of Preset's production RDS PostgreSQL instances in US East 1, from 14.7 to 17.9, ran far past its maintenance window, and all customers on the us2a deployment could not reach Superset. After more than five hours the upgrade failed with "Postgres cluster is in a state where pg_upgrade cannot be completed successfully."

   Service outageUpgrade stall

   Trigger

   A planned major version upgrade of all RDS instances in production US East 1 from PostgreSQL 14.7 to 17.9, started with a ModifyDBInstance API call at 04:12 EDT.

   Root cause

   Capacity exhaustion

   Component

   DatabaseDatabase backups and snapshots

   Contributing factor

   Unrepresentative stagingUnverified assumptionUnknown limitLimited debug access

   Detection

   The planned upgrade was being watched as it ran: the snapshot's I/O was observed at 05:28 EDT, the incident was posted on the status page at 06:00 EDT and an AWS support ticket was opened at 07:26 EDT.

   Remediation

   • AWS rolled the failed upgrade back automatically, and the instance restarted on PostgreSQL 14.15 at 10:13 EDT

   Action items

   • Rehearse the upgrade against a full production-scale dataset to check storage and timing estimates before any future major version upgrade

   Lessons

   Preset learned that RDS takes a full, non-incremental snapshot before a major version upgrade, so the duration of the daily incremental snapshots and of the upgrades in other regions said nothing about how long the pre-upgrade snapshot would take on this instance. The S3 snapshot throughput limit of about 30–45MB/s only becomes visible during such full snapshots, which are rare in normal operation.

   View case
2. IL-0281 PostHog's Logs ClickHouse cluster silently deleted almost all its S3 data, losing US logs older than 3 days

   PostHog2026

   Symptoms

   On 19 February 2026, a node of the ClickHouse cluster behind PostHog's Logs product crashed, restarted and could not start again because it could not find a large amount of its data. Engineers then found that almost all of the Logs data stored on S3 was gone, so logs collected in the US region more than 3 days earlier were lost. Only the Logs product was affected.

   Data loss

   Trigger

   At 10:54 UTC a routine mutation was run to materialise an index. When it finished at 11:02, it set off a bug in ClickHouse's zero-copy replication.

   Root cause

   Software defect

   Component

   DatabaseDatabase replicationObject storageDatabase backups and snapshots

   Contributing factor

   Monitoring blind spotSingle point of failureUntested backup

   Detection

   No automated alarm fired. At 19:40 UTC a node in the cluster crashed, restarted and failed to start because of the missing data, and the engineers who investigated found that most of the S3-backed data was gone.

   Remediation

   • Switched Logs to a new table without zero-copy replication and caught up on recent messages
   • Backfilled the Logs data from the 3 days of Kafka history

   Action items

   • Disable zero-copy replication on all clusters
   • Audit the whole Logs ClickHouse configuration and keep experimental features out of production
   • Enable S3 versioning on the storage buckets so objects deleted by a database bug can be recovered
   • Spot-check configurations and data integrity strategies for single points of failure before a product becomes generally available

   Lessons

   Running Logs in its own cluster kept every other product unaffected, and 3 days of Kafka retention saved the recent data. An experimental setting chosen for an early internal stage was allowed to stay in production. Monitoring covered only incoming and recent data, so petabytes were deleted over 8 hours without an alarm. Relying on database replication alone over shared storage was a single point of failure, and S3 versioning would have let the deleted files be recovered.

   View case
3. IL-0380 A compaction change in InfluxDB Cloud us-east-1 dropped data from compacted files, and queries missed data for weeks

   InfluxData2026

   Symptoms

   From 9 February 2026, InfluxDB Cloud customers on the AWS us-east-1 cluster prod101-us-east-1 found that some recent data did not show up in query responses. The first support ticket about data availability came in on 9 February, the day a compaction change was deployed, and more tickets followed on 10 February.

   Data lossResponse quality degradationHigh latency

   Trigger

   On 9 February 2026 InfluxData deployed to prod101-us-east-1 a compaction change that runs several compaction jobs in parallel on one partition, each on a subset of the data chosen by org id prefix.

   Root cause

   Faulty deployment

   Component

   DatabaseDatabase backups and snapshots

   Contributing factor

   Unsafe failure behaviourMissed in reviewGap in automated testsUnrepresentative staging

   Detection

   Tickets about data availability were raised, the first on 9 February and more on 10 February, when the status page reported that some recent data was not showing up in query responses.

   Remediation

   • Rolled back the compaction change
   • Restored recent data first, rebuilt from the Kafka logs
   • Changed the restoration process to make historical data recovery more efficient
   • Restored historical data from the weekly TSM snapshots
   • Kept the cluster online and restored data incrementally so ingest and queries could continue

   Action items

   • Expand test coverage for changes to critical storage components such as the compactor, with scenarios closer to production-scale workloads
   • Strengthen safeguards around compaction so failures are detected and handled safely
   • Review restoration workflows and procedures to reduce elevated TTBR and slow queries during large restores
   • Revisit the backup and restore strategy to speed up cluster-wide restorations

   View case
4. IL-0484 Slurm 24.05 to 25.05 upgrade broke GPU configuration on MIT CSAIL's cluster, and a failed downgrade kept it down

   MIT CSAIL2025

   Symptoms

   After a planned full day of downtime on Monday, September 8, 2025, to upgrade the MIT CSAIL Slurm compute cluster from Slurm 24.05 to Slurm 25.05, the Infrastructure Group found on Tuesday morning that the upgraded Slurm packages had been built without a feature the cluster needs for correct GPU configuration. The cluster did not return to normal operation until Wednesday morning, after a downgrade failed and the cluster was rebuilt.

   Upgrade stallService outage

   Trigger

   The upgrade from Slurm 24.05 to Slurm 25.05 on September 8 installed packages that were not compiled with a feature required for correct GPU configuration.

   Root cause

   Breaking change in an upgrade

   Component

   Slurm job schedulerDatabase backups and snapshots

   Contributing factor

   Ineffective rollbackUntested backup

   Detection

   On the Tuesday morning after the maintenance day, the team discovered that the upgraded Slurm packages were not compiled with the feature needed for GPU configuration.

   Remediation

   • Downgraded Slurm to the previous known-working version
   • Reinstalled the OS on all compute nodes and handled the nodes left in an intermediate state one by one
   • Re-deployed the cluster from scratch on a clean database

   Action items

   • Improve the testing and deployment processes based on the lessons of the outage

   Lessons

   The downgrade exposed flaws in the deployment and testing process: the deployment service could not reinstall every compute node at once, and the upgrade plan did not allow a simple downgrade or a working restore of the controller and database from backup.

   View case
5. 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

By root cause8