Incident Library
Applied filters Root causeOperator errorFactorAutomation amplificationClear 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

1 to 5 of 6

  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-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
  3. IL-0431 During Mackerel's move to AWS, PostgreSQL failed over to a replica that had stopped replicating, losing an hour of data
    Hatena2017
    Symptoms

    On 7 August 2017, while checking the application after the maintenance that moved Mackerel from an on-premises data center to AWS, the team found that data updated during a specific time window was missing. Everything written to the PostgreSQL database between 14:30 and 15:30 JST was gone.

    Data lossReplication lagNetwork unreachable
    Trigger

    One hour after the application was switched to the newly promoted primary db001, db001 lost network connectivity and the database failed over to the standby db002.

    Root cause
    Operator error
    Component
    DatabaseDatabase replicationDatabase failover manager
    Contributing factor
    Overlapping failuresUnreviewed defaultsUnrepresentative stagingAutomation amplification
    Detection

    The team found the missing data while checking how the application behaved after the migration work.

    Remediation
    • Tried to restore the lost updates by hand from the table data left on db001 and gave up
    • Tried point-in-time recovery from the base backup and WAL and gave up
    • Built a new replica db003 with db002 as primary to restore redundancy
    • Kept db001 in maintenance state for investigation
    • Watched db002 for some time to confirm the problem did not recur, then completed the migration
    Action items
    • Change the PostgreSQL replica creation script to set recovery_target_timeline = 'latest' in recovery.conf by default
    • Add a check to a server configuration test tool such as Serverspec that recovery.conf contains recovery_target_timeline = 'latest'
    Lessons

    A setting needed only for a rare layout, such as a grandchild replica during a migration, was applied by hand through a script option and was forgotten. Because recovery_target_timeline = 'latest' is harmless on ordinary standbys too, Hatena now sets it by default whenever a replica is created. The staging rehearsal used the same layout and steps but had the setting right, so it could not catch the mistake. Hatena notes that a similar layout may be used again for a future PostgreSQL upgrade or a move to another region.

    View case
  4. IL-0434 Rolling restarts of a 30-node Elasticsearch 0.19 cluster after a host failure left 12 shards unassigned
    CyberAgent2016
    Symptoms

    After an OpenStack host server went down and took one Elasticsearch node with it, the health check that the API servers run against Elasticsearch returned false, although the Head plugin showed the cluster status as green. The check stayed false after the node was brought back and the cluster was green again.

    High latencyData loss
    Trigger

    An OpenStack host server went down, and one node of the Elasticsearch cluster went down with it.

    Root cause
    Operator error
    Component
    Elasticsearch or OpenSearch
    Contributing factor
    Unverified assumptionAutomation amplification
    Detection

    The health check that the API servers run against Elasticsearch returned false while the Head plugin showed the cluster as green.

    Remediation
    • Migrated the Elasticsearch node's virtual server to another host after the failed host recovered
    • Started the node's Elasticsearch process and let it rejoin the cluster
    • Restarted all nodes in order from node 1, pausing at about the twentieth when the API slowed
    • Restarted all nodes again from node 1, which ended the API delays but left 12 shards unassigned
    • Tried to move an unassigned shard with the allocate command of _cluster/reroute, which failed
    • For index A, copied node 22's shard files to nodes 3 and 10 and set primary to true in node 22's state file
    • For index B, deleted the broken shard files on node 27, copied node 28's files to node 27 and other nodes and marked node 28 primary
    • For index C, copied shards 2 and 4 from nodes 27 and 25 to two other nodes each and marked the copies as not primary
    Action items
    • Upgrade Elasticsearch and stop running such an old version
    Lessons

    Automatic shard reallocation should have been turned off before restarting nodes. After each node restart, the next node should have been restarted only after reallocation had completely finished, not just after the log file looked fine.

    View case
  5. IL-0224 ELB control plane APIs failed in US-East, and load balancers it then changed broke, after ELB state data was deleted
    Amazon Web Services2012
    Symptoms

    From 12:24 PM PST on 24 December 2012, the Amazon Elastic Load Balancing (ELB) control plane in the US-East Region showed high latency and error rates for API calls that manage load balancers. Running load balancers kept handling requests normally at first.

    Control plane lagHigh error rateHigh latency
    Trigger

    One of the very few developers with access to the production ELB environment inadvertently ran a maintenance process against the production ELB state data, and it logically deleted part of that data.

    Root cause
    Operator error
    Component
    Cloud load balancer
    Contributing factor
    No safeguard on destructive changeUntested backupAutomation amplification
    Detection

    The ELB team noticed the control plane API errors first; the missing state data was found only after the team investigated load balancers that had become degraded.

    Remediation
    • Disabled several ELB control plane workflows, including scaling and descaling
    • Recovered some of the affected running load balancers by hand
    • Restored a snapshot of the ELB state data from just before the deletion, using an alternate recovery process
    • Merged the restored data with the state changes since the snapshot and verified it
    • Re-enabled the ELB workflows and APIs slowly while recovering each affected load balancer
    Action items
    • Require per-incident Change Management approval for all access to production ELB state data
    • Change the data recovery process so ELB state data can be recovered much faster
    • Reprogram the ELB control plane workflows to reconcile central service data with current load balancer state
    View case
Check your cluster for this

These 6 cases involve Backbone network (WAN) 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.

Open kubegap

By root cause1

Operator error6 cases

Component
Backbone network (WAN)2Database2Authoritative DNS servers and records2BGP routing1Cloud block storage1Cloud load balancer1Database replication1Elasticsearch or OpenSearch1Database failover manager1Object storage1
Contributing factor
Automation amplification6Signal buried in noise1Unverified assumption1Untested backup1Excessive blast radius1Circular dependency1Unreviewed defaults1Limited debug access1No safeguard on destructive change1No headroom1Overlapping failures1Retry storm1Unrepresentative staging1
Organisation
Amazon Web Services2CyberAgent1Hatena1Meta1Scaleway1
  1. IL-0348 Scaleway's FR-PAR region lost public internet connectivity when one 100 Gbps backbone link was saturated
    Scaleway2025
  2. IL-0221 A backbone maintenance command disconnected all Facebook data centers, and its DNS servers withdrew their BGP routes
    Meta2021
  3. IL-0431 During Mackerel's move to AWS, PostgreSQL failed over to a replica that had stopped replicating, losing an hour of data
    Hatena2017
  4. IL-0434 Rolling restarts of a 30-node Elasticsearch 0.19 cluster after a host failure left 12 shards unassigned
    CyberAgent2016
  5. IL-0224 ELB control plane APIs failed in US-East, and load balancers it then changed broke, after ELB state data was deleted
    Amazon Web Services2012
  6. IL-0337 EBS volumes in one US East Availability Zone got stuck after a network change cut EBS nodes off from their replicas
    Amazon Web Services2011