Incident Library
Applied filters Root causeSoftware defectComponentDatabaseFactorExcessive blast radiusClear 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-0347 About 25% of Scaleway FR-PAR-1 hypervisors lost VPC connectivity when both VPC BGP route reflectors got stuck
    Scaleway2024
    Symptoms

    On 18 October 2024, from 7:50 to 8:01 UTC, about 25% of the hypervisors in Scaleway's FR-PAR-1 availability zone lost VPC connectivity with the rest of the region, and products that use VPC failed with them. Public internet connectivity and Elastic Metal VPC connectivity were not affected.

    Network unreachablePacket lossNode NotReady
    Trigger

    At 6:20 UTC a Top of Rack switch in FR-PAR-1 had a software crash. One of the two BGP route reflectors for VPC ran on a hypervisor in that rack and was left in an abnormal state.

    Root cause
    Software defect
    Component
    Network control plane (SDN)BGP routingNetwork switchDatabaseManaged Kubernetes control plane and provider API
    Contributing factor
    Excessive blast radiusAutomation amplification
    Detection

    Health-check monitoring on both route reflectors detected the anomaly, and the Scaleway Customer Excellence and SRE teams detected the customer impact and opened an incident.

    Remediation
    • Fixed both VPC route reflectors by manual action
    Action items
    • Fixed the autohealing mechanism that had failed to fix route reflectors stuck in a stale state; the fix is https://github.com/FRRouting/frr/pull/17163
    • Run different software versions on the route reflectors so a single bug cannot stop several instances
    • Investigate the software issue that left the route reflectors in a stale state
    View case
  2. IL-0241 A database shard could not elect a new primary, and the Stripe API failed most requests in two periods on one day
    Stripe2019
    Symptoms

    On 10 July 2019 the Stripe API failed a substantial majority of requests twice, from 16:35 to 17:02 UTC and from 21:14 to 22:47 UTC. In the first period automated monitoring detected within a minute that a database cluster had failed to elect a new primary.

    High error rateFailover failureWrites rejectedIntermittent timeoutsSustained high node CPU
    Trigger

    The primary node of a database cluster failed at 16:35 UTC while one shard had several stalled nodes. The second period was set off by rolling the election protocol back to the previous minor version at 20:42 UTC.

    Root cause
    Software defect
    Component
    DatabaseDatabase failover manager
    Contributing factor
    Change with a delayed effectMonitoring blind spotExcessive blast radiusHarmful manual actionUnverified assumptionOverlapping failures
    Detection

    Automated monitoring detected the failed election within a minute, and the team was alerted at 16:36 UTC. The second period was announced at 21:14 UTC by automated alerts that some shards in the cluster were unavailable.

    Remediation
    • Restarted all nodes of the database cluster, which forced a successful primary election
    • Updated the production configuration and restarted the database cluster's nodes
    • Ramped traffic back up, putting services for user-initiated API requests first
    Action items
    • Alert when nodes stop reporting their replication lag
    • Alert when a shard enters a state that could trigger the election fault
    • Work with the database maintainers on a fix for the underlying fault
    • Add circuit breaking on failed operations to particular database clusters
    • Use fault isolation to contain the impact of a single failed shard
    • Limit the resources used by clients that keep retrying failed requests
    • Add procedures and tooling that make rapid configuration changes during incident response safer
    View case
Check your cluster for this

These 2 cases involve Database and BGP routing. 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

Software defect2 cases

Component
Database2BGP routing1Database failover manager1Managed Kubernetes control plane and provider API1Network control plane (SDN)1Network switch1
Contributing factor
Excessive blast radius2Unverified assumption1Automation amplification1Change with a delayed effect1Harmful manual action1Monitoring blind spot1Overlapping failures1
Organisation
Scaleway1Stripe1
  1. IL-0347 About 25% of Scaleway FR-PAR-1 hypervisors lost VPC connectivity when both VPC BGP route reflectors got stuck
    Scaleway2024
  2. IL-0241 A database shard could not elect a new primary, and the Stripe API failed most requests in two periods on one day
    Stripe2019