Incident Library
Applied filters Root causeOperator errorComponentAuthoritative DNS servers and recordsClear 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

Cases3 cases

1 to 3 of 3

  1. IL-0348 Scaleway's FR-PAR region lost public internet connectivity when one 100 Gbps backbone link was saturated
    Scaleway2025
    Symptoms

    On 10 March 2025 at 16:22 UTC, public internet connectivity in Scaleway's FR-PAR region broke for all products. Most internet traffic between the FR-PAR-2 availability zone and the rest of the PAR region was blackholed for about five minutes, while VPC traffic and Dedibox RPN kept working.

    Packet lossService outageHigh latency
    Trigger

    While Scaleway's network team connected a new data center to the FR-PAR backbone, a human mistake in a router configuration rerouted more than 1 Tbps of traffic between OpCore DC3 and DC5 through a single 100 Gbps link.

    Root cause
    Operator error
    Component
    Backbone network (WAN)Object storageAuthoritative DNS servers and records
    Contributing factor
    Automation amplification
    Detection

    The router configuration error was detected quickly and rolled back within four minutes.

    Remediation
    • Rolled back the router configuration, restoring the correct configuration at 16:27 UTC
    Action items
    • Harden the peer review and production communication process for changes
    • Add failsafes and tests before network configuration is applied at backbone level
    • Deploy the fix for the Object Storage synchronisation software issue
    View case
  2. IL-0531 Azure Database for MySQL Single Server and MariaDB in West US rejected every new connection for a batch of servers
    Microsoft Azure2024
    Symptoms

    From 04:26 UTC on 19 April 2024, every new connection to a subset of Azure Database for MySQL - Single Server and Azure Database for MariaDB servers in West US failed, and retries did not help. The first report came at 04:46 UTC from Azure Databricks, which told the MySQL team that multiple databases were unreachable.

    Service outageIntermittent timeouts
    Trigger

    At 04:26 UTC, during planned maintenance in West US, the DNS update that moves new incoming connections for a batch of MySQL and MariaDB servers to a new gateway ring was made, and a procedural error pointed it at a newly built gateway ring whose configuration was incomplete.

    Root cause
    Operator error
    Component
    DatabaseAuthoritative DNS servers and records
    Contributing factor
    Monitoring blind spot
    Detection

    Service telemetry did not detect the failure because the new gateway ring had no telemetry or monitoring configured yet. At 04:46 UTC Azure Databricks reported to the MySQL team that multiple databases were unreachable.

    Remediation
    • Rolled back the DNS change and moved all connections back to the previous working gateway ring after validation
    Action items
    • Add checks, testing and sign-off procedures before switching production gateway rings
    • Add Azure Databricks alerts that detect multiple databases becoming unavailable within a short time
    View case
  3. IL-0221 A backbone maintenance command disconnected all Facebook data centers, and its DNS servers withdrew their BGP routes
    Meta2021
    Symptoms

    On 4 October 2021 Facebook's platforms went down worldwide: every connection in Facebook's global backbone network was lost, and the data centers were cut off from each other and from the internet. The rest of the internet could no longer find Facebook's servers, because Facebook's authoritative DNS servers had become unreachable.

    Service outageDNS resolution failuresNetwork unreachable
    Trigger

    During routine maintenance of the backbone, a command was issued to assess the availability of global backbone capacity, and it unintentionally took down all connections in the backbone network.

    Root cause
    Operator error
    Component
    Backbone network (WAN)BGP routingAuthoritative DNS servers and records
    Contributing factor
    Automation amplificationCircular dependencyLimited debug access
    Remediation
    • Sent engineers onsite to the data centers to debug the issue and restart systems
    • Brought the backbone network back online across the data center regions
    • Brought services back gradually, managing the rising load to avoid crashes from a traffic surge
    Action items
    • Find ways to simulate the global backbone being taken offline in storm drills
    • Strengthen testing, drills and overall resilience
    Lessons

    The hardening that protects Facebook's data centers against unauthorized access slowed recovery from an outage caused by Facebook's own error, and the author judges that tradeoff worth keeping. Storm drills prepared the teams to bring load back safely, although no drill had yet simulated the global backbone going offline.

    View case
Check your cluster for this

These 3 cases involve Authoritative DNS servers and records 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 cause1

Operator error3 cases

Component
Authoritative DNS servers and records3Backbone network (WAN)2BGP routing1Database1Object storage1
Contributing factor
Automation amplification2Circular dependency1Limited debug access1Monitoring blind spot1
Organisation
Meta1Microsoft Azure1Scaleway1
  1. IL-0348 Scaleway's FR-PAR region lost public internet connectivity when one 100 Gbps backbone link was saturated
    Scaleway2025
  2. IL-0531 Azure Database for MySQL Single Server and MariaDB in West US rejected every new connection for a batch of servers
    Microsoft Azure2024
  3. IL-0221 A backbone maintenance command disconnected all Facebook data centers, and its DNS servers withdrew their BGP routes
    Meta2021