Incident Library
Applied filters ComponentDatabaseSymptomLock contention or deadlockOrganisationMIT Open LearningClear 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

Cases1 case

1 to 1 of 1

  1. 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.

    Trigger

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

    Root cause
    Component
    Contributing factor
    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.

Check your cluster for this

This case involves 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.

By root cause1