Cases11 cases

1 to 5 of 11

1. IL-0510 MIT Learn's RDS PostgreSQL ran out of storage after a release and learn.mit.edu returned 503s and 504s for hours

   MIT Open Learning2026

   Symptoms

   On 24 March 2026 learn.mit.edu went down shortly after a regular release. An engineer reported the outage with a linked Sentry issue, and Sentry soon showed many 504 responses from the site.

   Service outageNode disk fullDatabase overloadLock contention or deadlock

   Trigger

   A regular release deployed a query pattern change to the learning resource APIs that put an aggregation inside the main query.

   Root cause

   Faulty deployment

   Component

   Database

   Contributing factor

   Inefficient queryUnrepresentative stagingHarmful manual action

   Detection

   An engineer reported the outage with a linked Sentry issue, and Sentry showed many 504 responses. The RDS FreeStorageSpace metric showed that the database had used up its storage.

   Remediation

   • Rolled back the release's query pattern change
   • Deleted the read replica so the database could flush its buffered WAL files
   • Terminated all active queries running longer than 10 minutes with pg_terminate_backend, after the backup finished and with guidance from AWS Support

   Action items

   • Explore enabling enhanced analytics on the production Learn database
   • Document rollback steps on the platform engineering documentation site
   • Make easy rollback part of the new release management framework
   • Alert on DiskQueueDepth for production databases without making the alert too noisy
   • Alert when API and site response times are more than 30% above normal
   • Run a gameday on an example production database outage
   • Adopt Rootly for incident management, with an automatic channel and an automatic incident transcript
   • Write an outage runbook: start a call, have the on-call engineer watch metrics until they return to baseline, and give one person the communications
   • Put the query that terminates long-running queries, and a version that finds them for selective termination, into a production Postgres runbook
   • Open an issue on redesigning the Learn Resource View Event model, which is only used for counts
   • Use anonymised production data generation tools to bring RC up to production data volume, on separate infrastructure for load testing
   • Change the view count to use a precomputed column

   Lessons

   The change was reviewed by senior engineers and showed no problems locally or on RC, but data scale and load in production are very different, and nothing in the system's health showed that adding a COUNT aggregation would make disk usage explode.

   View case
2. IL-0369 Railway's backend API went down when a column migration waited on locks and replicas could not get database connections

   Railway2025

   Symptoms

   At 15:18 UTC on 9 December 2025, Railway's backend replicas became unhealthy and stopped serving traffic. Dashboard access, CLI operations, logins, the API and the processing of GitHub-based deployments were disrupted, while running deployments stayed online.

   Probe failuresLock contention or deadlockDatabase overloadService outage

   Trigger

   Engineers merged a database schema change with a data migration at 15:03 UTC, and the migration began applying at 15:17 UTC. It added a nullable column to a heavily used table of about 1 billion rows.

   Root cause

   Faulty deployment

   Component

   DatabaseDatabase proxy and connection poolerSchema migrationLiveness and readiness probes

   Contributing factor

   Health check tied to a dependency

   Action items

   • Increase database connections and reconfigure PgBouncer to work within those limits
   • Fix the long-running query so it no longer causes row lock issues

   View case
3. IL-0547 Buildkite annotation queries timed out and drove database CPU up across shards after a migration removed an index

   Buildkite2025

   Symptoms

   From 04:48 UTC on 10 November 2025, queries on the table that stores annotations in Buildkite Pipelines timed out, CPU load on the affected databases rose sharply, and the Agent API, the REST API, GraphQL and the Web UI slowed down and returned more errors.

   Intermittent timeoutsDatabase overloadHigh error rateHigh latency

   Trigger

   At 04:48 UTC a database migration removed an index on the annotations table of the Pipelines product.

   Root cause

   Faulty deployment

   Component

   Database

   Contributing factor

   Missed in reviewNo staged rollout

   Detection

   At 04:53 UTC the impact of the removed index was detected as queries timing out on the annotations table.

   Remediation

   • Recreated the removed index, finishing on about half of the database shards by 05:30 UTC
   • Temporarily revoked the application user's permission to read from and write to the annotations table
   • Increased max_parallel_maintenance_workers in Postgres to speed up index creation
   • Finished recreating the index on the remaining shards between 07:50 and 08:43 UTC
   • Freed the agents and cleaned up the job states left inconsistent, handling by hand the cases the system could not self-heal, by 11:56 UTC

   Action items

   • Extend the internal tooling that flags risky migrations in code review to cover index removals and ask engineers to verify an index is no longer needed
   • Roll out high-risk migrations to shards in phases instead of to all shards at once
   • Evaluate tools such as HypoPG to analyse index creation and removal
   • Show index usage data from pganalyze more prominently in the development workflow
   • Automate the manual cleanup of inconsistent agent states so the system can heal itself

   Lessons

   Buildkite said the incident was mainly caused by a database migration that exposed gaps in its review process.

   View case
4. IL-0315 Railway's backend API went down when an index build locked a billion-row Postgres table and used up every connection

   Railway2025

   Symptoms

   At 18:36 UTC on 28 October 2025, two minutes after a database change went live in production, Railway's internal monitoring alerted and paged the engineering team. The dashboard could not be opened, CLI operations that use the API, such as railway up, failed, GitHub-based deployments were delayed because webhook processing failed, and all Railway Public API operations were disrupted.

   Service outageLock contention or deadlockDatabase overload

   Trigger

   A routine schema change to the backend's Postgres database, introduced at 18:23 UTC and live in production at 18:34 UTC, that added a new column with an index without the CONCURRENTLY option.

   Root cause

   Faulty deployment

   Component

   DatabaseDatabase proxy and connection pooler

   Contributing factor

   No configuration testsLimited debug access

   Detection

   Internal monitoring alerts paged the engineering team at 18:36 UTC, and the incident was declared at 18:41 UTC.

   Remediation

   • The index migration finished after about 30 minutes and released the table lock, and the queued operations and connection pools recovered

   Action items

   • Enforce CONCURRENTLY for all index creation in CI and block pull requests that do not use it
   • Adjust PgBouncer pool limits so they cannot overwhelm the Postgres instance's capacity
   • Configure database user connection limits so administrative access stays possible during incidents

   View case
5. IL-0327 After a blue/green upgrade of CircleCI's workflows database every query hit disk, and workflow starts lagged or failed

   CircleCI2025

   Symptoms

   On April 3, 2025, from 22:08 to 23:45 UTC, CircleCI customers saw higher latency and some failures when starting and cancelling workflows and jobs, and had delays and trouble viewing workflows in the UI. Nine minutes after the blue/green cutover of the workflows database, the team found increased latency in the workflows service and errors from jobs dropped after using up their 10 minutes of retries.

   High latencyHigh error rateDatabase overload

   Trigger

   A blue/green upgrade of the database behind the CircleCI workflows service cut over to the new database at 22:08 UTC.

   Root cause

   Faulty deployment

   Component

   DatabaseQuery planner and table statistics

   Contributing factor

   –

   Detection

   At 22:17 UTC the team identified increased latency in the workflows service and errors from jobs dropped after exhausting their 10-minute retries.

   Remediation

   • Restarted the workflows pods so all of them connected to the correct database
   • Upsized the new database and disabled non business critical operations on it
   • Scaled the workflows service down to a single pod while the statistics table was rebuilt
   • Re-enabled writes on the old database and restored it as primary

   Action items

   • Run an analysis procedure after every major version change in blue/green database deployments
   • Tested running analyze on a database under pressure, found it does not degrade performance further, and noted this for future remediation
   • Add automated tests and manual checkpoints throughout migrations to catch problems before the blue/green cutover

   View case

By root cause1