Incident Library
  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases2 cases

1 to 2 of 2

  1. Symptoms

    On 2 November 2020 the Cloudflare API and dashboard were degraded for six hours and 33 minutes. The success rate of API queries dropped at times to 75%, and the dashboard was up to 80 times slower than normal, while Cloudflare's edge network kept working.

    Trigger

    At 14:43 UTC a network switch in a control plane data center partly failed: it kept LACP and BGP running but stopped forwarding some packets, and it recovered on its own six minutes later.

    Root cause
    Component
    Contributing factor
    Detection

    At 14:43 UTC alerts fired because the misbehaving switch was unreachable to pings. Engineers then saw that the primary authentication database was overwhelmed.

    Remediation
    • Shed load from the primary authentication database by slowing SSL certificate pushes to the edge, emails and other features
    • Moved API traffic that could use read replicas to the secondary data center by hand
    • Sent authentication calls fully back to the primary data center when the dashboard got worse
    • Rebuilt the first database replica, which put itself back into service at 21:20 UTC and returned performance to normal
    • Ramped the turned-down services back up so asynchronous processing could catch up
    Action items
    • Remove the cluster management limitation that requires rebuilding all replicas after a primary is promoted
    • Redesign the user sessions system so dashboard traffic can be steered between data centers
    • Change the auto-remediation configuration so a database replica is not promoted so quickly
    • Tune each system involved to be more resilient to failures of its dependencies
    Lessons

    Every system in the chain had redundancy and none failed completely; each only degraded, which made the chain of events much harder to model and foresee. Automating replica promotion so that it could trigger on a minute's notice had been a point of pride, but for at least one database a fast promotion can do more harm than the failure it answers. Most general-purpose cluster managers use Raft or Paxos rather than Byzantine fault tolerant protocols, accepting a rare failure mode in exchange for a protocol that is simpler to implement correctly and debug.

  2. Symptoms

    On Saturday, September 27, 2014 at 6:50 p.m. UTC, Mailgun saw that all its database replicas and the internal traffic between its environments in all regions were broken and reporting timeouts. Once Rackspace began rebooting cloud instances in its Chicago data center (ORD), Mailgun customers had intermittent connection failures.

    Trigger

    Rackspace, Mailgun's parent company and hosting provider, rebooted cloud instances in its Chicago data center (ORD), and the cloud maintenance triggered an error condition on Mailgun's F5 load balancers.

    Root cause
    Component
    Contributing factor
    –
    Detection

    Mailgun noticed at 6:50 p.m. UTC on September 27 that all database replicas and the internal traffic between its environments were broken and reporting timeouts.

    Remediation
    • The Rackspace networking team cleared the cached path MTU on Mailgun's F5s and on some Rackspace dedicated customers' F5s
    • Set up a new virtual IP for Mailgun services
    • Changed Mailgun's DNS settings, which forced the remote F5s to clear their caches
    Action items
    • Finish the root cause analysis of the F5 path MTU problem with Rackspace
    • Make sure maintenance of Mailgun's cloud infrastructure has no impact on Mailgun customers
Check your cluster for this

These 2 cases involve Database replication and Cloud load balancer. 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