Incident Library
Applied filters Root causeFaulty deploymentSymptomService outageFactorNo configuration testsClear 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

Cases2 cases

1 to 2 of 2

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

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

    Trigger

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

    Root cause
    Component
    Contributing factor
    Remediation
    • Issued a fix, after which the dashboard and ingestion recovered
    Action items
    • Replace RunSQL commands with more robust solutions in the migration framework
    • Update the database framework to the latest version, which handles some operations RunSQL was used for
    • Write runbooks for recovering from lock or timeout issues during migrations
    • Improve alerting and observability so the team reacts sooner
Check your cluster for this

These 2 cases involve Database and Database proxy and connection pooler. 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