Incident Library
Applied filters ComponentDatabase replicationOrganisationCloudflareClear 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 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.

Check your cluster for this

This case involves Coordination and key-value store and 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