Incident Library
Applied filters OrganisationSentryClear 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

    On 21 October 2024 Sentry could not ingest data in US SaaS from 9:42 AM to 10:06 AM PT, and the status page reported elevated errors for ingestion. The same failure had also happened on 4 and 16 October.

    Trigger

    In each of the three incidents an ingestion region saw an increase in backlogged traffic; the trigger was different each time.

    Root cause
    Component
    Contributing factor
    Action items
    • Create more, smaller edge regions to reduce the chance of cascading failures, adding one region each in South America, North America and Europe
    • Change the autoscaling rules to use stronger signals than CPU load
    • Scale down more slowly so that iowait-based backlogs do not trigger scale-down events
    • Improve the metrics the edge produces to refine the autoscaling rules and their sensitivity
  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 Automated capacity manager and CDN and edge network. 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 cause2