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

Cases5 cases

1 to 5 of 5

  1. IL-0545 Wasabi API calls in all regions returned HTTP 5XX when the message queue stopped spreading requests over database nodes
    Wasabi2024
    Symptoms

    From 00:17 UTC on 30 November 2024, client connections to Wasabi Cloud Storage and the Web Console failed in every storage region, and all API calls returned HTTP 5XX errors.

    Service outageLoad imbalance
    Root cause
    unknown
    Component
    Message brokerDatabase
    Contributing factor
    –
    Remediation
    • Configured internal servers by hand to route requests across multiple database instances, which restored service
    • After service was restored, worked on the root cause by recovering the internal messaging queue and resuming its automated handling of client requests
    View case
  2. IL-0441 A ZOZO SQL Server database stalled and applications hit timeout storms whenever batch executions peaked in sales
    ZOZO2021
    Symptoms

    From around mid-2020, a SQL Server database behind one ZOZO feature made the applications throw many timeout errors whenever batch executions per second passed a certain threshold.

    Intermittent timeoutsDatabase overloadLock contention or deadlock
    Trigger

    Traffic increases during sales and lucky-bag launches pushed batch executions per second on the database above a threshold.

    Root cause
    unknown
    Component
    Database
    Contributing factor
    –
    Remediation
    • Fixed the plan guides of the four stored procedures whose compilation waits caused blocking
    • Disabled automatic statistics updates on the affected tables during periods of expected high traffic
    • Enabled automatic statistics updates again once traffic calmed down
    • Compressed the large indexes held in the data cache to use memory more efficiently
    Lessons

    When the root cause of a failure cannot be found, choosing among the things observed during the failure those that can be removed or reduced, and acting on them, can still create a state in which the failure no longer happens.

    View case
  3. IL-0335 A bugcheck in the primary SQL Server put the Stack Exchange network into read-only mode and then offline for 12 minutes
    Stack Exchange2017
    Symptoms

    On January 24, 2017 at 17:53 UTC the Stack Exchange network, including Stack Overflow, went into read-only mode for about 5 minutes and then went offline for 12 minutes. It took the team 2 minutes to notice the problem, 5 minutes to locate its source and 10 minutes to restore service.

    Writes rejectedService outageFailover failureData loss
    Trigger

    At 17:53 UTC the primary SQL Server, NY-SQL02, triggered a bugcheck in the SQL Server process.

    Root cause
    unknown
    Component
    Database
    Contributing factor
    Single point of failure
    Remediation
    • Restarted the SQL service on NY-SQL02, which brought the network back online in read-only mode
    • Put the sites back into read-write mode after a sanity check of SQL health
    • Brought the network online without waiting for the memory dump to complete
    • Took NY-SQL02 out of production for testing, including a memory test, and ran the normal load on NY-SQL01
    • Brought the SQL cluster up to 2016 SP1 CU1
    View case
  4. IL-0387 Mailgun MongoDB secondaries were overloaded by rising connections, and a rollback then moved reads onto the primary too
    Mailgun2017
    Symptoms

    On 12 January 2017 at 14:09 UTC, Mailgun engineers began responding to alerts for the click and open tracking services and the primary MongoDB clusters in one production region. Within ten minutes the engineers found that the MongoDB secondary servers, which serve most reads, were under heavy load and slow to answer, which also caused the tracking errors. The status page reported intermittent timeouts on the Control Panel, API, SMTP and tracking links.

    Database overloadIntermittent timeoutsHigh error rate
    Trigger

    A gradual increase in connections to the MongoDB secondary servers, which coincided with several MongoDB configuration changes made the day before. A rollback of those changes then also introduced, by mistake, a change that moved the API and SMTP services from the secondaries to the primary.

    Root cause
    unknown
    Component
    Database
    Contributing factor
    Harmful manual actionSingle point of failure
    Detection

    Alerts for the click and open tracking services and the primary MongoDB clusters at 14:09 UTC.

    Remediation
    • Rolled back the previous day's MongoDB configuration changes through several pull requests from 15:15 UTC
    • Resized the MongoDB servers to handle more connections
    • Deployed connection limits at the MongoDB server level
    • Limited the number of connections the services could open to the MongoDB primary
    • Redeployed the configuration that makes services prefer secondary servers for reads
    Action items
    • Run the tracking infrastructure across two independent regions
    • Limit the number of connections every service can open to the database
    • Permanently increase the size of the primary Mongo cluster and roll the change out to the other data centers
    • Let click redirection keep working when downstream services fail
    View case
  5. IL-0393 Load on the BBC programme metadata database surged and metadata requests failed, leaving BBC iPlayer down over a weekend
    BBC2014
    Symptoms

    At 9.30 on Saturday 19 July 2014, the load on the database of the BBC system that provides programme and clip metadata rose sharply, and many requests for metadata to its application servers started to fail. BBC iPlayer, BBC iPlayer Radio and audio and video playback on other parts of bbc.co.uk were affected.

    Database overloadHigh error rateService outage
    Root cause
    unknown
    Component
    Database
    Contributing factor
    No cachingOverlapping failures
    Remediation
    • Restored the failed pool of the caching layer first
    • Switched the BBC homepage to its emergency mode until the cache was stable
    • Did significant remedial work on the metadata system from Saturday afternoon into the evening
    • Ran the service in a reduced state through the weekend and did the full restoration on Monday morning
    Action items
    • Complete the forensics on the root causes and put measures in place to reduce the chance of similar interruptions
    View case
Check your cluster for this

These 5 cases involve Database and Message broker. 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.

Open kubegap

By root cause1

unknown5 cases

Component
Database5Message broker1
Contributing factor
Single point of failure2Harmful manual action1No caching1Overlapping failures1
Organisation
BBC1Mailgun1Stack Exchange1Wasabi1ZOZO1
  1. IL-0545 Wasabi API calls in all regions returned HTTP 5XX when the message queue stopped spreading requests over database nodes
    Wasabi2024
  2. IL-0441 A ZOZO SQL Server database stalled and applications hit timeout storms whenever batch executions peaked in sales
    ZOZO2021
  3. IL-0335 A bugcheck in the primary SQL Server put the Stack Exchange network into read-only mode and then offline for 12 minutes
    Stack Exchange2017
  4. IL-0387 Mailgun MongoDB secondaries were overloaded by rising connections, and a rollback then moved reads onto the primary too
    Mailgun2017
  5. IL-0393 Load on the BBC programme metadata database surged and metadata requests failed, leaving BBC iPlayer down over a weekend
    BBC2014