Cases2 cases

1 to 2 of 2

1. IL-0561 DigitalOcean's Cloud Control Panel and Public API returned up to 25% errors in two windows as authorization timed out

   DigitalOcean2026

   Symptoms

   From 16:56 UTC on 24 August 2026, requests to DigitalOcean's Cloud Control Panel, Public API and the product management systems that depend on them failed at elevated rates. Automated monitoring flagged abnormal error rates and latency at 16:58. Running Droplets, network routing and block storage Volumes kept working.

   High error rateHigh latency

   Trigger

   A planned migration of the database layer behind DigitalOcean's identity, authentication and authorization services made one critical authorization query run much slower than its historical baseline.

   Root cause

   Configuration change

   Component

   DatabaseIdentity and access service

   Contributing factor

   Retry stormHarmful manual action

   Detection

   Automated monitoring detected abnormal error rates and latency at 16:58 UTC, two minutes after the authorization query slowed down.

   Remediation

   • Rerouted authorization traffic onto a single healthy processing path
   • Temporarily disabled hedged retries for the primary callers
   • Disabled the retry and amplification behaviour across the remaining affected services
   • Added read capacity for the slow authorization query

   Action items

   • Deploy circuit breakers in upstream services that detect a degraded downstream dependency and suppress hedged requests and retries
   • Audit the architecture so retry suppression and circuit breaking are enforced the same way in every control plane service
   • Add fast-fail load shedding so request queues do not saturate while a dependency is slow
   • Add telemetry alerts that spot queues backing up before customers are affected
   • Let critical authorization components run in a degraded mode on asynchronous, eventually consistent database replicas when the primary database is slow

   View case
2. IL-0392 MariaDB replication of section x1 between eqiad and codfw broke on a missing heartbeat row during a cookbook run

   Wikimedia Foundation2024

   Symptoms

   On 18 September 2024, while a cookbook was reconfiguring Wikimedia's core MariaDB databases from one-way eqiad -> codfw replication to circular replication ahead of a datacenter switchover, replication in the codfw -> eqiad direction broke on the x1 and es6 sections. Engineers watching the run noticed at 21:28 UTC that the x1 primary was not replicating.

   Replication lag

   Trigger

   Running the cookbook sre.switchdc.databases.prepare, which set up codfw -> eqiad replication and started pt-heartbeat, on the row-based x1 and es sections.

   Root cause

   Configuration change

   Component

   DatabaseDatabase replication

   Contributing factor

   Monitoring blind spotGap in automated testsHarmful manual action

   Detection

   Engineers watching the first run of the automation saw on orchestrator that the x1 primary was not replicating, because monitoring of circular replication was not yet enabled. The break in the eqiad -> codfw direction was reported by Icinga.

   Remediation

   • Skipped replication of the heartbeat tables with Replication_wild_ignore_table='heartbeat.%'
   • Inserted the missing heartbeat row with binary logging off on the es hosts
   • Inserted the missing heartbeat row with binary logging off on the x1 codfw hosts and removed the ignore rule

   Action items

   • Avoid the same issue again, probably by inserting the missing row when it is detected
   • Add a post-maintenance health check that replication works in both directions
   • Add options to run the maintenance in another order or on each section individually
   • Update the Phabricator task for each section rather than only at the end
   • Fix the monitoring gaps for circular replication
   • Made pt-heartbeat-wikimedia use STATEMENT format for its session on the x1 and row-based read-write es hosts, fixed in a later deploy

   Lessons

   Circular replication is not a normal working mode, so the first fix only moved the break to the other side; TRUNCATE would have worked better than DELETE because it always replicates as a statement, but it was not considered because it is more dangerous. Running sql_skip_slave_counter was avoided, since it could have made things worse or lost data. The check of the replication channel should also run once all tasks are complete, not only right after setup. The combination of row-based replication, pt-heartbeat and differing heartbeat rows was not described in earlier maintenance or documentation.

   View case

By root cause1