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-0325 DigitalOcean's control panel and API were down for 4 hours 56 minutes after the production primary database was deleted

   DigitalOcean2017

   Symptoms

   At 10:24 AM EDT on April 5th, 2017, DigitalOcean began to receive alerts that its public services were not working, and by 10:27 the team had verified that the production database on the primary had been deleted. The control panel and the API were unavailable for four hours and fifty-six minutes: running Droplets kept working, but no new Droplets or other resources could be created or managed.

   Service outage

   Trigger

   A process performing automated testing had been misconfigured with production credentials, and the production primary database was deleted.

   Root cause

   Configuration change

   Component

   DatabaseDatabase replicationDatabase backups and snapshots

   Contributing factor

   No safeguard on destructive change

   Detection

   Alerts at 10:24 AM EDT that public services were not functioning; within three minutes the team found that the primary database had been deleted.

   Remediation

   • Began recovery from a time-delayed database replica
   • Took a backup of the time-delayed replica
   • Copied the backup to the primary and recovered it
   • Copied the backups to the replicas until all systems were restored

   Action items

   • Drastically reduce access to the primary system for certain actions
   • Upgrade network connectivity between database servers
   • Update hardware to speed up recovery
   • Assess further safeguards against developer error
   • Improve the processes around data recovery
   • Explore ways to provide better real-time information to customers during future customer-impacting events

   View case

By root cause1