Incident Library
Applied filters ComponentBGP routingSymptomHigh latencyClear 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

Cases7 cases

1 to 5 of 7

  1. IL-0394 A Cloudflare router in Miami leaked IPv6 BGP routes to peers and providers for 25 minutes, congesting the backbone
    Cloudflare2026
    Symptoms

    On 22 January 2026 from 20:25 UTC, a Cloudflare edge router in Miami sent unintended BGP advertisements of IPv6 prefixes to its transit providers and peers. External networks' traffic was funnelled into the Miami data center, the backbone between Miami and Atlanta became congested, and some Cloudflare customer traffic saw elevated loss and higher latency.

    Packet lossHigh latency
    Trigger

    At 20:25 UTC Cloudflare's policy automation pushed a change, merged at 19:52 UTC, that removed the BGP announcements from Miami for a data center in Bogotá, Colombia, by deleting the prefix-list 6-BOG04-SITE-LOCAL from several export policy terms.

    Root cause
    Configuration change
    Component
    BGP routingBackbone network (WAN)
    Contributing factor
    No configuration tests
    Detection

    The network team began investigating unintended route advertisements from Miami at 20:40 UTC, and an incident was raised at 20:44 UTC.

    Remediation
    • A network operator reverted the bad configuration change on the Miami router by hand
    • Paused the automation for the router so it could not run again
    • Reverted the triggering change in the network automation code repository
    • Unpaused the automation on the Miami router after confirming it ran without the routing policy bug
    Action items
    • Patch the failure in the routing policy automation that caused the leak
    • Add BGP community-based safeguards that reject routes received from providers and peers on external export policies
    • Add automatic routing policy evaluation to the CI/CD pipelines that looks for empty or erroneous policy terms
    • Detect problems in network configurations and the effects of automated changes earlier
    • Validate routing equipment vendors' implementations of RFC9234 before rolling out BGP roles and the Only-to-Customer Attribute
    • Encourage long-term adoption of RPKI Autonomous System Provider Authorization (ASPA)
    Lessons

    Removing only the prefix lists from export policy terms left terms that were too permissive, because a match on route-type internal accepts IBGP routes as well. Cloudflare states that route leaks are easy to cause by accident and that RFC9234 is the only way, independent of routing policy, to prevent route leaks caused at the local AS.

    View case
  2. IL-0341 Traffic between Cloudflare and AWS us-east-1 had high latency, packet loss and origin failures for almost four hours
    Cloudflare2025
    Symptoms

    From 16:27 UTC on 21 August 2025, users connecting to Cloudflare from servers in AWS us-east-1, or receiving connections from Cloudflare there, saw high latency, packet loss and failures to reach origins. Cloudflare's network team was alerted to internal congestion in Ashburn (IAD) at 16:44 UTC.

    Packet lossHigh latencyIntermittent timeouts
    Trigger

    At about 16:27 UTC a single customer began sending many requests from AWS us-east-1 to Cloudflare for objects in Cloudflare's cache, doubling the total traffic from Cloudflare to AWS.

    Root cause
    Capacity exhaustion
    Component
    Transit gateway or network interconnectBGP routingCDN and edge network
    Contributing factor
    No headroomHarmful manual actionExcessive blast radius
    Detection

    Cloudflare's network team was alerted to internal congestion in Ashburn (IAD) at 16:44 UTC, and an incident was raised for customer impact at 17:45 UTC.

    Remediation
    • Rate limited the single customer whose traffic caused the surge
    • Took further traffic engineering actions that fully resolved the congestion
    • Asked AWS to revert its BGP prefix withdrawals, which AWS finished at 20:07 UTC
    Action items
    • Build a mechanism to deprioritise a customer's traffic when it congests the network enough to affect others
    • Speed up the Data Center Interconnect upgrades to add network capacity
    • Work with AWS so the two companies' BGP traffic engineering actions do not conflict
    • Build a traffic management system that gives each customer a network resource budget and automates the manual actions used here
    Lessons

    Cloudflare concludes that it must isolate customers better so that no single customer can take over shared network resources and degrade the platform for others, and that its network needs enough capacity to meet demand. It describes the outage as the result of insufficient network congestion management during an unusual high-traffic event.

    View case
  3. IL-0342 DigitalOcean's AMS3, LON1 and SFO2 data centers lost Internet connectivity in repeated waves as edge routers failed
    DigitalOcean2023
    Symptoms

    From 09:55 UTC on 9 August 2023, DigitalOcean's AMS3, LON1 and SFO2 datacenters lost Internet access in waves of 10 to 15 minutes, about an hour apart. Users saw connectivity issues, latency and timeout errors on Droplets and on Droplet-based services such as Load Balancers, Kubernetes and Database clusters.

    Network unreachableIntermittent timeoutsHigh latency
    Trigger

    The edge routers received an RPKI-related routing update, and the operating system software on them crashed its routing process on that update.

    Root cause
    Software defect
    Component
    BGP routing
    Contributing factor
    Excessive blast radiusHarmful manual action
    Remediation
    • Rolled out a software update to the edge routers running the affected version, site by site
    • Rebalanced traffic on the congested routes between AMS3 and FRA1
    • Rolled out the fix to the redundant networking equipment so a failover would not hit the bug
    Action items
    • Upgrade all global edge routers to remove the bug
    • Bring the network upgrades already done in Asia to Europe and North America
    View case
  4. IL-0225 An IGP purge command made every Microsoft WAN router recompute routes, causing global latency, timeouts and packet loss
    Microsoft Azure2023
    Symptoms

    From 07:08 UTC on 25 January 2023, customers saw long network latency and timeouts when connecting to resources in Azure regions and to other Microsoft services such as Microsoft 365 and Power Platform. Microsoft's monitoring detected DNS and WAN issues from 07:11 UTC.

    High latencyIntermittent timeoutsIntermittent connection failuresPacket lossNetwork unreachable
    Trigger

    A network engineer adding capacity to the global WAN in Madrid ran a step of a recently changed standard operating procedure that purged the IGP database; on the router manufacturer involved, that command runs on all IGP-joined routers instead of only the local one.

    Root cause
    Configuration change
    Component
    Backbone network (WAN)Interior routing (IGP)BGP routing
    Contributing factor
    No configuration testsUnverified assumptionExcessive blast radiusHarmful manual action
    Detection

    Monitoring detected DNS and WAN issues from 07:11 UTC and alerted the on-call engineers within 5 minutes of the command being run. The team reviewed all recent changes and identified the command by 08:20 UTC. The engineer making the change was not informed of the alerts because of the unqualified changes to the SOP.

    Remediation
    • Restarted by hand the paused WAN health and traffic engineering systems, which ended the remaining packet loss
    Action items
    • Audit and block similar widespread-impact commands across all three vendors for all WAN router roles
    • Give on-call engineers real-time visibility of approved and unqualified activity on network devices
    • Run regular mandatory operational training and attestation of following all SOPs
    • Have the Change Advisory Board review all SOPs still pending qualification within 30 days
    View case
  5. IL-0255 Basecamp's two redundant links between data centers dropped together and a Redis replica resync loop stalled chat
    37signals2020
    Symptoms

    At 11:59AM CDT on Friday 28 August 2020, Basecamp's Ops team received a flood of alerts from PagerDuty, Nagios and Prometheus. Monitoring showed that the newer of the two metro links between the data centers in Ashburn, VA and Chicago, IL had been lost for about 20-30 seconds, and BC3 kept responding slowly after the link came back.

    Link flappingHigh latencyReplication lag
    Trigger

    Both redundant metro links between Basecamp's Ashburn and Chicago data centers dropped for short periods; monitoring showed the newer link down for about 20-30 seconds.

    Root cause
    Dependency failure
    Component
    Backbone network (WAN)BGP routingIn-memory cacheDatabase replication
    Contributing factor
    Single point of failureRetry stormSignal buried in noise
    Detection

    A flood of alerts from PagerDuty, Nagios and Prometheus, with monitoring showing the lost metro link. A lingering alert for one Redis DB instance later pointed to the replication problem.

    Remediation
    • Turned chat off at the load balancer layer so the rest of BC3 could stabilise
    • Restarted Redis on the replica that was stuck in the resynchronization loop
    Action items
    • Make the documented Redis configuration changes for the known replication issue
    • Make concrete plans to remove the shared physical path under the two metro links
    • Prove the failover systems in production at peak load
    • Make explicit room for post-incident follow-up work and push other work out
    Lessons

    Planned redundancy and live testing had given Basecamp a false sense of security, especially at peak load: moving between redundant network links or shifting load across data centers should work without issue, and Basecamp would rather find out in a controlled test with the full team ready. The follow-up from an outage needs urgency and explicitly cleared time, not just a place on a list.

    View case
Check your cluster for this

These 7 cases involve BGP routing and Backbone network (WAN). 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 cause4

Configuration change2 cases

Component
Backbone network (WAN)2BGP routing2Interior routing (IGP)1
Contributing factor
No configuration tests2Unverified assumption1Excessive blast radius1Harmful manual action1
Organisation
Cloudflare1Microsoft Azure1
  1. IL-0394 A Cloudflare router in Miami leaked IPv6 BGP routes to peers and providers for 25 minutes, congesting the backbone
    Cloudflare2026
  2. IL-0225 An IGP purge command made every Microsoft WAN router recompute routes, causing global latency, timeouts and packet loss
    Microsoft Azure2023

Capacity exhaustion1 case

Component
BGP routingCDN and edge networkTransit gateway or network interconnect
Contributing factor
Excessive blast radiusHarmful manual actionNo headroom
Organisation
Cloudflare
  1. IL-0341 Traffic between Cloudflare and AWS us-east-1 had high latency, packet loss and origin failures for almost four hours
    Cloudflare2025

Software defect2 cases

Component
BGP routing2Backbone network (WAN)1Network control plane (SDN)1
Contributing factor
Excessive blast radius2Circular dependency1Limited debug access1Harmful manual action1Ineffective rollback1
Organisation
DigitalOcean1Google Cloud1
  1. IL-0342 DigitalOcean's AMS3, LON1 and SFO2 data centers lost Internet connectivity in repeated waves as edge routers failed
    DigitalOcean2023
  2. IL-0222 Google Cloud US regions had heavy packet loss and some went unreachable after the network control plane was descheduled
    Google Cloud2019

Dependency failure2 cases

Component
Backbone network (WAN)2BGP routing2In-memory cache1Database replication1Network control plane (SDN)1
Contributing factor
Signal buried in noise1Retry storm1Single point of failure1
Organisation
37signals1Packet1
  1. IL-0255 Basecamp's two redundant links between data centers dropped together and a Redis replica resync loop stalled chat
    37signals2020
  2. IL-0358 Packet Public Cloud locations had high latency and unreachable paths from routing loops and blackholed traffic
    Packet2019