Incident Library
Applied filters ComponentDDoS protection serviceSymptomService outageFactorLimited debug accessClear 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

Cases1 case

1 to 1 of 1

  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

This case involves BGP routing and DDoS protection service. 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 cause1