Incident Library
Applied filters Root causeDependency failureComponentDatabase replicationFactorSingle point of failureClear 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

Cases2 cases

1 to 2 of 2

  1. IL-0526 OpenStreetMap.org went offline, then read-only, for 56 hours after HE.net routing equipment cut both fibre uplinks
    OpenStreetMap Foundation2024
    Symptoms

    At 04:01 UTC on 15 December 2024, StatusCake monitoring sent SMS alerts that OpenStreetMap.org was unreachable. The website and the mapping API had gone completely offline at 03:53 UTC.

    Network unreachableService outage
    Trigger

    HE.net's routing equipment in Amsterdam failed at 03:53 UTC on 15 December 2024.

    Root cause
    Dependency failure
    Component
    ISP and transit networksDatabase replication
    Contributing factor
    Single point of failureNo runbook
    Detection

    StatusCake monitoring detected the outage at 04:01 UTC and sent SMS alerts, and the incident was reported to the operations team at once.

    Remediation
    • Activated a read-only backup instance of OpenStreetMap.org in Dublin
    • Brought a new Equinix Internet link into service in Amsterdam, bypassing HE.net and restoring full functionality
    • HE.net replaced its routing hardware and restored its service, and routing through HE.net resumed
    Action items
    • Move to a multi-ISP architecture so another provider can take over when one fails
    • Research backup ISPs for the Amsterdam servers, including BGP and keeping HE.net as a fallback
    • Add deeper route and latency monitoring and an automated escalation protocol
    • Hold failover drills for switching between ISPs and keep replication up to date
    • Agree SLAs with HE.net and Equinix Internet with defined escalation procedures and response times
    • Prepare the 4G out-of-band system as a manual fallback uplink that can sync Postgres replication data, and upgrade its hardware
    • Document outage communication procedures and delegate communication during outages
    • Investigate decoupling the OAuth service so authentication keeps working while the database is read-only
    Lessons

    Relying on HE.net alone left the Amsterdam servers with a single point of failure, so OpenStreetMap will keep multiple upstream providers. The 4G out-of-band link proved invaluable and should be able to carry data synchronisation. Resumed replication would have restored editing faster than the read-only backup. Frequent contact with the ISP gave no useful estimates, so the SLA needs to be better understood. Alerting on upstream connectivity needs refining, and a read-only OpenStreetMap.org also blocked logins to services that were not affected, because it could not save new tokens.

    View case
  2. IL-0255 Basecamp's two redundant links between data centers dropped together and a Redis replica resync loop stalled chat
    37signals2020
    Symptoms

    At 11:59AM CDT on Friday 28 August 2020, Basecamp's Ops team received a flood of alerts from PagerDuty, Nagios and Prometheus. Monitoring showed that the newer of the two metro links between the data centers in Ashburn, VA and Chicago, IL had been lost for about 20-30 seconds, and BC3 kept responding slowly after the link came back.

    Link flappingHigh latencyReplication lag
    Trigger

    Both redundant metro links between Basecamp's Ashburn and Chicago data centers dropped for short periods; monitoring showed the newer link down for about 20-30 seconds.

    Root cause
    Dependency failure
    Component
    Backbone network (WAN)BGP routingIn-memory cacheDatabase replication
    Contributing factor
    Single point of failureRetry stormSignal buried in noise
    Detection

    A flood of alerts from PagerDuty, Nagios and Prometheus, with monitoring showing the lost metro link. A lingering alert for one Redis DB instance later pointed to the replication problem.

    Remediation
    • Turned chat off at the load balancer layer so the rest of BC3 could stabilise
    • Restarted Redis on the replica that was stuck in the resynchronization loop
    Action items
    • Make the documented Redis configuration changes for the known replication issue
    • Make concrete plans to remove the shared physical path under the two metro links
    • Prove the failover systems in production at peak load
    • Make explicit room for post-incident follow-up work and push other work out
    Lessons

    Planned redundancy and live testing had given Basecamp a false sense of security, especially at peak load: moving between redundant network links or shifting load across data centers should work without issue, and Basecamp would rather find out in a controlled test with the full team ready. The follow-up from an outage needs urgency and explicitly cleared time, not just a place on a list.

    View case
Check your cluster for this

These 2 cases involve Database replication 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

Dependency failure2 cases

Component
Database replication2Backbone network (WAN)1BGP routing1In-memory cache1ISP and transit networks1
Contributing factor
Single point of failure2Signal buried in noise1No runbook1Retry storm1
Organisation
37signals1OpenStreetMap Foundation1
  1. IL-0526 OpenStreetMap.org went offline, then read-only, for 56 hours after HE.net routing equipment cut both fibre uplinks
    OpenStreetMap Foundation2024
  2. IL-0255 Basecamp's two redundant links between data centers dropped together and a Redis replica resync loop stalled chat
    37signals2020