Incident Library
Applied filters Root causeHardware failureSymptomService outageFactorSingle 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

Cases3 cases

1 to 3 of 3

  1. IL-0508 All SourceHut services went down when the main database server remilia.sr.ht failed in hardware and became unreachable
    SourceHut2023
    Symptoms

    At about 13:40 UTC on 11 January 2023, alerts started firing for most SourceHut services being unavailable, along with one for remilia.sr.ht, the physical host that is SourceHut's main database server. The database server could not be reached remotely at all.

    Service outage
    Trigger

    remilia.sr.ht, the main database server, suffered a hardware failure at about 13:38 UTC.

    Root cause
    Hardware failure
    Component
    Database
    Contributing factor
    Single point of failureLimited debug access
    Detection

    Alerts fired at about 13:40 UTC for most services and for remilia.sr.ht itself, after Prometheus started failing to scrape remilia at 13:38.

    Remediation
    • Sent SourceHut's emergency on-call contact in the datacenter area to go on site
    • Moved remilia's disks into the chassis of build worker cirno1.sr.ht and brought it online as remilia
    Action items
    • Make the off-site database copy able to serve as a failover database host
    • Re-prioritize the migration to the EU
    • Set up new database failover
    • Add a new EU build worker to backfill build capacity
    • Record a better hardware inventory for future reference
    View case
  2. IL-0525 OpenStreetMap.org went offline for 7h 27m when its uplink switch lost power during a data-centre power feed maintenance
    OpenStreetMap Foundation2022
    Symptoms

    From 20:18 UTC on 11 June 2022, OpenStreetMap.org was unavailable: all of its services hosted in Amsterdam, including www, the API, the wiki and planet, had no connectivity to the Internet. The outage began 18 minutes into Equinix's planned maintenance of power feed A at the Amsterdam data centre.

    Network unreachableService outage
    Trigger

    Equinix's planned 5-year maintenance of power feed A in Amsterdam, which started at 20:00 UTC on 11 June 2022.

    Root cause
    Hardware failure
    Component
    Network switchData center power and cooling
    Contributing factor
    Single point of failureLimited debug accessMonitoring blind spot
    Remediation
    • Waited for the end of the Equinix power feed A maintenance window instead of failing over to Dublin or moving the uplink; connectivity returned at 03:45 UTC
    Action items
    • Acknowledge ongoing outages faster
    • Add monitoring and alerting of switch PSU and FAN states
    • Replace the Cisco SG550X-48 switches and the Redundant Power System with Juniper EX4300 switches with redundant power supplies
    • Install out-of-band access equipment with dual power feeds in Amsterdam
    • Install redundant uplinks
    • Make site failover easier, less manual and lower risk
    • Introduce an on-call pager system for the operations SRE
    • Expand the SRE team
    • Continue and formalise fail-over tests for power, network, upstream link and service outages
    View case
  3. IL-0370 Render Postgres databases in Frankfurt were down up to 65 minutes as their disks stayed attached to a failed node
    Render2022
    Symptoms

    At 08:30 UTC on 23 May 2022, every user Postgres database on one node in Render's Frankfurt region went completely down after the node, supplied by Render's external cloud provider, had a hardware issue and failed its status check. The database instances could not start on a healthy node because their disks were still attached to the failed node.

    Service outageStorage disconnected or stale mounts
    Trigger

    A node supplied by Render's external cloud provider had a hardware issue and failed its status check at 08:30 UTC on 23 May 2022.

    Root cause
    Hardware failure
    Component
    DatabaseCloud block storage
    Contributing factor
    Single point of failure
    Detection

    An alert that fires when databases have been stuck in one state while starting up for at least 15 minutes paged the on-call engineer automatically at 08:57 UTC.

    Remediation
    • Manually terminated the failed node at about 09:27 UTC so the disks could attach to healthy nodes
    Action items
    • Create an alert that fires sooner than the current 15-minute startup alert
    • Make it easier to identify the correct corrective action, and eventually automate it
    • Review incident procedures so the status page reflects reliability accurately
    • Build high availability for Postgres so a primary's node hardware failure causes minimal downtime
    Lessons

    Hardware issues are rare but expected, so Render's mitigations aim at detecting them sooner and shortening the time to resolve them.

    View case
Check your cluster for this

These 3 cases involve Database and Cloud block storage. 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

Hardware failure3 cases

Component
Database2Cloud block storage1Data center power and cooling1Network switch1
Contributing factor
Single point of failure3Limited debug access2Monitoring blind spot1
Organisation
OpenStreetMap Foundation1Render1SourceHut1
  1. IL-0508 All SourceHut services went down when the main database server remilia.sr.ht failed in hardware and became unreachable
    SourceHut2023
  2. IL-0525 OpenStreetMap.org went offline for 7h 27m when its uplink switch lost power during a data-centre power feed maintenance
    OpenStreetMap Foundation2022
  3. IL-0370 Render Postgres databases in Frankfurt were down up to 65 minutes as their disks stayed attached to a failed node
    Render2022