Incident Library
Applied filters Root causeOperator errorSymptomHigh latencyFactorAutomation 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

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-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
  3. 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 3 cases involve Backbone network (WAN) and Cloud load balancer. 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
Backbone network (WAN)1Cloud load balancer1Authoritative DNS servers and records1Elasticsearch or OpenSearch1Object storage1
Contributing factor
Automation amplification3Unverified assumption1Untested backup1No safeguard on destructive change1
Organisation
Amazon Web Services1CyberAgent1Scaleway1
  1. IL-0348 Scaleway's FR-PAR region lost public internet connectivity when one 100 Gbps backbone link was saturated
    Scaleway2025
  2. IL-0434 Rolling restarts of a 30-node Elasticsearch 0.19 cluster after a host failure left 12 shards unassigned
    CyberAgent2016
  3. 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