Incident Library
  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases16 cases

16 to 16 of 16

  1. Symptoms

    At 4.50am Melbourne time on Sunday 7 February (evening of 6 February UTC), FastMail became unavailable and stayed unreachable for almost two hours. Traffic to FastMail's public IP range never made it into FastMail's own network.

    Trigger

    The GRE tunnels between Level 3 and NYI, which carried FastMail's filtered traffic into its network, went down.

    Root cause
    Component
    Contributing factor
    Detection

    NYI, the datacentre provider, noticed the failure quickly.

    Remediation
    • NYI escalated with Level 3's support until FastMail's public IP ranges were pointed back to NYI
    Action items
    • Go back to DDoS protection from Black Lotus under NYI's explicit control
    • Build nginx frontends in the Los Angeles datacentre that reach NYI over the secondary network, and point DNS to them if NYI's primary network fails
    • Add hardware in Amsterdam and change the delivery system so it depends less on NYI
    • Work with NYI to understand its processes for detecting and responding to network faults
    Lessons

    Much of FastMail's and NYI's reliability had come from NYI controlling its own infrastructure. With protection always on at Level 3, NYI could not restore the routes itself, and FastMail calls the resulting delay in restoring service unacceptable.

Check your cluster for this

These 16 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.

By root cause6

Configuration change5 cases

  1. IL-0400 Public sector sites across Wales lost connectivity for over 8 hours as a PE router wrongly advertised a default route
    PSBA2026
  2. IL-0225 An IGP purge command made every Microsoft WAN router recompute routes, causing global latency, timeouts and packet loss
  3. IL-0266 Eqiad routers looped traffic between each other after a BGP MED change and could not reach other sites' public IPs
  4. IL-0539 KT's internet service failed nationwide for about 89 minutes as wrong routes spread from one router in Busan
    KT2021
  5. IL-0228 IPv4 routing across OVHcloud's global network broke after a router change put the full internet routing table into OSPF

Capacity exhaustion1 case

Organisation
  1. IL-0350 Hosts in an IONOS TXL cluster lost connectivity when an InfiniBand fabric resweep failed on a full multicast table

Faulty deployment1 case

Contributing factor
Organisation
  1. IL-0563 Linode servers lost connectivity in all data centers as route servers built incomplete BGP route tables
    Linode2025

Software defect4 cases

  1. IL-0233 A VPC control plane release broke IP alias routes in Nebius eu-west1, and Managed Kubernetes pods lost connectivity
    Nebius2025
  2. IL-0347 About 25% of Scaleway FR-PAR-1 hypervisors lost VPC connectivity when both VPC BGP route reflectors got stuck
  3. IL-0342 DigitalOcean's AMS3, LON1 and SFO2 data centers lost Internet connectivity in repeated waves as edge routers failed
  4. IL-0222 Google Cloud US regions had heavy packet loss and some went unreachable after the network control plane was descheduled

Dependency failure4 cases

  1. IL-0509 SourceHut was down for 170 hours after a DDoS led its upstream network to null-route the PHL datacenter's subnet
  2. IL-0267 Wikimedia's eqsin cache site went unreachable when both of its transport links to the core data centers were down
  3. IL-0358 Packet Public Cloud locations had high latency and unreachable paths from routing loops and blackholed traffic
    Packet2019
  4. IL-0258 FastMail was unreachable for almost two hours when the GRE tunnels carrying its traffic from Level 3 went down

Operator error1 case

Organisation
  1. IL-0221 A backbone maintenance command disconnected all Facebook data centers, and its DNS servers withdrew their BGP routes
    Meta2021