Incident Library

IL-0554 Sentry · 2024-10-10database

A database migration used up Sentry US's Postgres connections, and the site and event ingestion were down for 22 minutes

On 10 October 2024 a database migration in Sentry US ran certain operations through the RunSQL command. Sentry's systems lacked safety checks that would have caught missing lock and statement timeouts in the SQL being executed, so queries ran for a long time and used up the connections to the Postgres database. With its connections exhausted, the database became inaccessible, and the Sentry US site and ingestion were down from 3:42 PM to 4:04 PM PT. A fix was issued, after which the dashboard and ingestion recovered.

Severity
–
Scope
Sentry US dashboard, API and all US ingestion (errors, transactions, attachments, profiles, replays, spans, cron monitoring, custom metrics)
Users affected
–
Region
Sentry US
Time to detect
–
Time to resolve
22m

Symptoms

From 3:42 PM to 4:04 PM PT on 10 October 2024, the Sentry US site and event ingestion were unavailable, and the status page reported an issue with the Postgres database that made the site unavailable. The dashboard, the API and every US ingestion type, including errors, transactions, attachments, profiles, replays, spans, cron monitoring and custom metrics, were affected.

Symptom Service outageDatabase overload

Root cause

Trigger
A database migration ran certain database operations through the RunSQL command without lock and statement timeouts.

Detection

–

Remediation

Action items

Lessons

–

Sources

Related cases

Check your cluster for this

kubegap audits a Kubernetes cluster for conditions like the ones in this case, Database, Schema migration among them, read-only, from Claude Code or Codex. Its checks cite public reports like this one.

For AI tools and scripts

The API needs no key. The MCP server offers search_incidents, get_incident, list_incidents, get_topic and vocab; both are explained on API and MCP.