Incident Library
Applied filters ComponentDatabaseSymptomDatabase overloadOrganisationMailgunClear 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 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.

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