Incident Library
Applied filters ComponentCDN and edge networkFactorExcessive blast radiusClear 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

Cases6 cases

3 to 6 of 6

  1. IL-0555 Sentry's ingestion edge regions backlogged one after another and rejected traffic in three incidents in October 2024
    Sentry2024
    Symptoms

    On 21 October 2024 Sentry could not ingest data in US SaaS from 9:42 AM to 10:06 AM PT, and the status page reported elevated errors for ingestion. The same failure had also happened on 4 and 16 October.

    High error rateService outageAutoscaler misbehaviour
    Trigger

    In each of the three incidents an ingestion region saw an increase in backlogged traffic; the trigger was different each time.

    Root cause
    Capacity exhaustion
    Component
    CDN and edge networkAutomated capacity manager
    Contributing factor
    Automation amplificationExcessive blast radius
    Action items
    • Create more, smaller edge regions to reduce the chance of cascading failures, adding one region each in South America, North America and Europe
    • Change the autoscaling rules to use stronger signals than CPU load
    • Scale down more slowly so that iowait-based backlogs do not trigger scale-down events
    • Improve the metrics the edge produces to refine the autoscaling rules and their sensitivity
    View case
  2. IL-0339 Azure Front Door and Azure CDN users saw intermittent connection errors, timeouts and latency spikes for hours
    Microsoft Azure2024
    Symptoms

    From 11:45 UTC on 30 July 2024, a subset of customers got intermittent connection errors, timeouts and latency spikes when connecting to Microsoft services that use Azure Front Door (AFD) and Azure Content Delivery Network (CDN). The Azure Portal team saw the first service degradation at 11:47 UTC.

    Intermittent connection failuresIntermittent timeoutsHigh latencyPacket loss
    Trigger

    Around 11:45 UTC the Azure network DDoS protection service was disengaging after a routine DDoS mitigation and returning traffic to its default routing to AFD, but the routes at one site in Europe could not be updated because the network control plane could not reach that site during a local power outage.

    Root cause
    Configuration change
    Component
    CDN and edge networkDDoS protection serviceNetwork control plane (SDN)Data center power and cooling
    Contributing factor
    Overlapping failuresExcessive blast radiusMonitoring blind spot
    Detection

    The Azure Portal team detected service degradation at 11:47 UTC and began to investigate. At 12:10 UTC network monitoring correlated the Portal incident to a network issue at one site in Europe, and networking engineers joined.

    Remediation
    • Rerouted traffic under the standard congestion playbook, which removed most of the impact by 13:58 UTC
    • Ordered the network control plane to reissue its commands to the misbehaving device, which could not be reached
    • Removed the device that kept attracting traffic from the network and scanned the network for other issues
    Action items
    • Add the missing configuration on network devices so a DDoS mitigation issue in one geography cannot spread to another
    • Improve validation and monitoring in the Azure network to detect invalid configurations
    • Improve monitoring for when the DDoS protection service is unreachable from the control plane but still serving traffic
    View case
  3. IL-0491 Squarespace's CDN origin fleet fell below its healthy node threshold, and images, scripts and stylesheets failed to load
    Squarespace2019
    Symptoms

    At 12:10 AM ET on Tuesday, February 12, 2019, Squarespace's monitoring alerted the on-call engineer for the CDN origin fleet that the fleet had fallen below a safe number of healthy nodes. Requests to static.squarespace.com and static1.squarespace.com failed, so images, scripts and style sheets did not load for some sites, and the status page later reported elevated error rates serving media and stylesheets.

    High error rate
    Trigger

    At 10:30 PM ET on February 11, an engineer started a maintenance operation across the CDN origin fleet. The operation kept running in the background after the engineer believed it had been terminated.

    Root cause
    Operator error
    Component
    CDN and edge network
    Contributing factor
    Excessive blast radiusMonitoring blind spot
    Detection

    The monitoring system alerted the CDN origin fleet's on-call engineer at 12:10 AM ET when the fleet fell below a safe number of healthy nodes.

    Remediation
    • Restored the CDN origin fleet, partially by 2:15 AM ET and to normal behaviour at 2:20 AM ET
    Action items
    • Revise the incident-response playbooks with checks and actions for this fleet, starting with an assessment of customer impact and the immediate involvement of an Incident Commander
    • Improve external monitoring to assess customer impact of issues with the CDN partners and origin services more quickly
    • Revise operational policies and add safeguards for issuing maintenance commands, including limiting the share of the fleet a command can operate on
    • Reduce the need for direct manual maintenance operations
    • Create independent failure domains and route requests automatically around unhealthy parts of the system
    View case
  4. IL-0338 Google Cloud HTTP(S) and TCP/SSL Proxy load balancers returned 502s or reset connections on 33% to 87% of requests
    Google Cloud2018
    Symptoms

    From 12:17 to 12:49 PDT on 17 July 2018, Google Cloud HTTP(S) Load Balancers answered a share of requests with 502 return codes, and connections to TCP/SSL Proxy Load Balancers were reset. The share of failed requests moved between 33% and 87% during those 32 minutes, and automated monitoring alerted Google engineers at 12:19.

    High error rateConnection resetsHigh latency
    Trigger

    A configuration change in the production environment intermittently set off a bug in a new feature of the second-layer Google Front Ends.

    Root cause
    Software defect
    Component
    Cloud load balancerCDN and edge network
    Contributing factor
    Gap in automated testsExcessive blast radius
    Detection

    Automated monitoring alerted Google's engineering team at 12:19 PDT, two minutes after the 502s began.

    Remediation
    • Reverted the configuration change at 12:44 PDT, which stopped the GFE restarts
    Action items
    • Add safeguards that disable features not yet in service
    • Harden the GFE testing stack against latent bugs in production binaries that make a task restart
    • Isolate the shards of GFE pools further from each other to reduce the scope of failures
    • Build a consolidated dashboard of all configuration changes for GFE pools
    View case
Check your cluster for this

These 6 cases involve CDN and edge network and BGP routing. 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

Software defect2 cases

Component
CDN and edge network2Cloud load balancer1Authoritative DNS servers and records1
Contributing factor
Excessive blast radius2Gap in automated tests2Change with a delayed effect1Ineffective rollback1
Organisation
Google Cloud1Microsoft Azure1
  1. IL-0226 Azure Front Door edge servers crashed worldwide on incompatible configuration metadata, causing timeouts and DNS errors
    Microsoft Azure2025
  2. IL-0338 Google Cloud HTTP(S) and TCP/SSL Proxy load balancers returned 502s or reset connections on 33% to 87% of requests
    Google Cloud2018

Capacity exhaustion2 cases

Component
CDN and edge network2BGP routing1Automated capacity manager1Transit gateway or network interconnect1
Contributing factor
Excessive blast radius2Automation amplification1Harmful manual action1No headroom1
Organisation
Cloudflare1Sentry1
  1. IL-0341 Traffic between Cloudflare and AWS us-east-1 had high latency, packet loss and origin failures for almost four hours
    Cloudflare2025
  2. IL-0555 Sentry's ingestion edge regions backlogged one after another and rejected traffic in three incidents in October 2024
    Sentry2024

Configuration change1 case

Component
CDN and edge networkData center power and coolingDDoS protection serviceNetwork control plane (SDN)
Contributing factor
Excessive blast radiusMonitoring blind spotOverlapping failures
Organisation
Microsoft Azure
  1. IL-0339 Azure Front Door and Azure CDN users saw intermittent connection errors, timeouts and latency spikes for hours
    Microsoft Azure2024

Operator error1 case

Component
CDN and edge network
Contributing factor
Excessive blast radiusMonitoring blind spot
Organisation
Squarespace
  1. IL-0491 Squarespace's CDN origin fleet fell below its healthy node threshold, and images, scripts and stylesheets failed to load
    Squarespace2019