From 08:06 UTC to 13:41 UTC, users may have experienced issues accessing the Support Portal, creating new support tickets, or reviewing existing support requests.
Our Engineering team has confirmed the full resolution of the issue affecting the Support Portal following a fix from our upstream provider. We have verified that the Support Portal, ticket creation, and ticket review are now operating normally.
If you continue to experience problems, please open a ticket with our support team. We apologize for any inconvenience and appreciate your patience.
This incident is now resolved. Power redundancy has been fully restored, and we have confirmed that customer impact has been mitigated. We are closing this incident.
Between 16:56 UTC and 23:09 UTC on August 24, 2026, customers using DigitalOcean’s Cloud Control Panel, Public API, and dependent product management systems experienced elevated request error rates, peaking at 25%, in two distinct windows totaling 3.5 hours of active degradation within a 6-hour span. Running Droplets, network routing, and block storage (Volumes) remained fully functional and unaffected throughout the event. No customer data loss occurred.
The event was initiated during a planned infrastructure migration of the database layer supporting identity, authentication, and authorization services. The migration introduced increased execution latency for a critical authorization query. In response to the elevated query latency, multiple upstream services initiated automated hedged retries. This secondary request amplification led to queue buildup in excess of the authentication service pool's processing throughput, resulting in cascading request timeouts across the authorization path.
To mitigate the initial degradation, engineering teams rerouted authorization traffic onto a single healthy processing path and temporarily disabled hedging for primary callers, successfully restoring service availability. However, upon returning traffic to the standard multipath routing configuration, lingering query latency combined with retry behavior from unhedged callers caused recurrent queue saturation, leading to the second window of degradation.
2. Impact
Active customer accounts (<2%) experienced one or more API or Control Panel request failures during the event windows.
Aggregate failure rates across both impact windows averaged approximately 10% of authenticated requests, with a peak error rate of 25% during the second window.
Affected management control planes included the Cloud Control Panel, Public API, Kubernetes cluster authentication, Container Registry, and Serverless / AI Inference endpoints.
Data plane components—including active Droplets, network routing, and block storage volumes—maintained 100% availability, as established connections do not depend on the affected authorization control path. There was zero data loss.
3. Current state
All impacted control plane services have been restored to nominal operational capacity. The database infrastructure migration has been completed. Remediation controls have been validated to ensure system stability against similar query latency scenarios.
4. Preventing recurrence
To prevent future occurrences and enhance systemic resilience, DigitalOcean has implemented the following technical enhancements:
Automated Request Throttling and Circuit Breaking:
Deployed automated circuit breakers across upstream services to detect downstream dependency degradation and automatically suppress hedged/retry amplification. Completed a broad architecture audit to ensure retry suppression and circuit breaking are uniformly enforced across all control plane services.
Queue Management and Load Shedding:
Implemented fast-fail load-shedding mechanisms to prevent request queue saturation during dependency slowness, accompanied by proactive telemetry alerts to identify queue backing prior to customer impact.
Graceful Service Degradation:
Configured critical authorization components to operate in degraded execution modes utilizing asynchronous, eventually-consistent data replicas during primary database latency events.
5. Timeline
| Time UTC | Event |
| --- | --- |
| 16:56 | A specific authorization query began running significantly slower than its historical baseline. |
| 16:58 | Automated monitoring detected abnormal error rates and latency; detected within 5 minutes of impact starting. |
| 17:05–18:52 | Operators tuned retry configuration and consolidated requests to a healthy service instance (first unavailability window closed). |
| 21:30 | Shifting traffic back to the production pattern caused the same saturation problem (second unavailability window begins). |
| 21:30–23:09 | Teams disabled the retry/amplification behavior across the remaining affected services and added additional read capacity for the slow query. Service was restored to a stable state. |
Our Engineering team has resolved the issue preventing cluster creation on Managed Databases in the NYC3 and NYC1 regions. Customers can now create new Managed Databases Clusters normally.
Our Engineering team has monitored the environment to ensure stability. We sincerely apologize for any inconvenience this disruption may have caused to your operations. If you continue to experience issues, please open a ticket with our Support team: https://cloudsupport.digitalocean.com/s/
Our Engineering team has confirmed that the issue impacting Container Registry and Spaces accessibility has been resolved.
Spaces accessibility via the Cloud Control Panel is now restored, and pushing and pulling container images is succeeding as expected. Customers who previously encountered these issues should now be able to access Spaces and deploy their container images without further issues.
If you continue to experience any problems, please open a ticket with our support team. Thank you for your patience, and we apologize for any inconvenience.
Our Engineering team has confirmed the regional control plane is healthy and CPU Droplets, Managed databases, Load balancers, Block storage, Kubernetes (DOKS) and Spaces are operating normally.
GPU Droplets continue to be impacted and our teams are working to restore all nodes. We will communicate with GPU Droplet customers separately via Slack and email with more information and regular updates.
Thank you for your patience throughout this incident. If you continue to experience any issues, please open a support ticket from within your account.
Between Aug 13, 09:50 UTC and 14:30 UTC, customers in the FRA1 region experienced an issue affecting Block Storage Volumes attachment and detachment operations on Droplets and Managed Kubernetes clusters.
During this window, customers may have encountered delays or been unable to attach and detach Block Storage Volumes from their resources.
Block Storage Volumes attachment and detachment operations now appear to be functioning normally, and customers should no longer experience issues with these operations. For Managed Kubernetes clusters specifically, some residual cleanup of affected volume attachments may still be needed, and our team is actively working through this.
We apologize for any inconvenience this may have caused. If you continue to experience issues with Block Storage Volumes operations, please don't hesitate to open a support ticket for further investigation. Our team will be happy to assist you.
Our Engineering team confirms the full resolution of the issue affecting all impacted services, including new account registration, Droplet Creation, Reserved IPs, Automated Backups and Snapshots, Droplet Autoscale, DOKS clusters, GenAI services, the Droplet Console, and Database cluster creation.
We apologize for the inconvenience. If you continue to experience any issues, please open a support ticket from within your account.
Our Engineering team has confirmed that the issue affecting Functions on App Platform has been fully resolved. Functions builds, deploys, and requests to Functions endpoints are all working as expected. The fix implemented earlier was successful, and we are no longer seeing any problems affecting Functions.
However, if you continue to experience any issues, please don't hesitate to raise a support ticket for further investigation.
Between Aug 6, 06:42 UTC and 09:08 UTC, customers experienced failures with write operations across multiple DigitalOcean services, including Managed Databases, DOKS, Cloud Firewalls, DNS, Spaces, Block Storage Volumes, and event processing.
Customers attempting to update Cloud Firewall rules, modify DNS records, manage object storage operations, provision or scale DOKS clusters and node pools, and make other infrastructure configuration changes experienced failures. These operations returned errors, preventing customers from managing their resources. Additionally, event processing was delayed or failed during this window, which may have impacted the timeliness of resource status updates and notifications.
The services have recovered and are now operating normally. Customers should no longer experience issues with write operations, configuration changes, or event processing.
We apologize for any inconvenience this may have caused. If you continue to experience issues with any of these services, please don't hesitate to open a support ticket. Our team will be happy to assist you.