Hosting / Cloud / DigitalOcean

DigitalOcean

OPERATIONAL

Since Apr 2026 · 50 incidents · status.digitalocean.com · checked just now

CompareStatus page
GradeFLast 90 days
FPRODBSHIP

Overview

30d90d1y
Admitted uptimeTime not covered by a Sev 1 the provider posted itself. A best case.
100.000%Grade F
IncidentsEverything posted on the status page except scheduled maintenance.
180 Sev 1
Sev 1 downtimeTotal minutes of Sev 1 incidents, as posted.
0m
Median fixMedian time to resolve. Half of incidents were fixed faster.
4h 02m
LongestLongest single incident, start to resolved.
25h 50m
Since lastTime since the last counted incident was resolved.
9d 2h

By area

FProduction
12INCIDENTS
3d 8hAFFECTED
Your users are hit: apps, APIs, databases, inference
Worst, 90d
SEV 2Aug 24, 2026 · 25h 50mCloud Control Panel and API
SEV 2Jul 27, 2026 · 20h 53mAgent Platform Requests Returning HTTP 500 Errors
SEV 2Jul 29, 2026 · 12h 19mResponse Degradation Impacting Kimi-K3
Most hit
Global5
Kubernetes - Global3
Spaces - Global2
Managed Databases - Global2
Worse. 36 in the last 6 months, 2 in the 6 before.
BShipping
12INCIDENTS
2d 11hAFFECTED
You can't deploy, build or manage: CI, CLI, dashboard, auth, billing
Worst, 90d
SEV 2Aug 24, 2026 · 25h 50mCloud Control Panel and API
SEV 2Aug 19, 2026 · 8h 25mMajor Service Interruption in MKC1
SEV 3Aug 23, 2026 · 9h 22mManaged Databases Creation
Most hit
Global6
Managed Databases - Global3
App Platform - Global2
Cloud Control Panel2
Worse. 18 in the last 6 months, 0 in the 6 before.
CleanSev 3–4Sev 1–2No data

What it costs

One small production web app, per month512 MB app on all month, 1M requests, 100 GB out, commercial use, one seat. Cheapest plan that runs it.
App Platform, shared 512 MB2 of 8 cheaper · Cloudflare: cheaper, same grade
$6/mo
apps-s-1vcpu-0.5gb (includes 50 GiB transfer)$5
50 GiB extra transfer at $0.02/GiB$1

docs.digitalocean.com · checked Oct 22, 2026 · Wrong price?

Trend, last 12 months

Worse. 48 in the last 6 months, 2 in the 6 before.

Severity mix

Sev 1 · Lights outProd site, API or database down, or data loss0
Sev 2 · BleedingProd degraded or partly down12
Sev 3 · Can't shipCan't deploy, build or manage it4
Sev 4 · PapercutDocs, status page, slow dashboard2

When it breaks

Start times, last 12 months, UTC.

What breaks

Global15 incidents
Managed Databases - Global7 incidents
Agent Runtime6 incidents
Inference6 incidents
Agentic Inference Cloud - Inference6 incidents
App Platform - Global5 incidents

Communication

Updates eachStatus page updates per incident, on average.
3.2Last 12 months
Update gapMedian time between status page updates during an incident.
1h 18mLast 12 months
PostmortemsSev 1–2 incidents with a published write-up.
1 of 37Sev 1–2

Incident history

Oct 13, 20260mSEV 3
App Platform DeploymentsFrom 04:34 to 12:15 UTC, DigitalOcean App Platform customers could not reliably deploy new apps or scale existing ones because a software update stopped containers starting on newly provisioned nodes. Running applications were unaffected. Engineering rolled back the update and restored the nodes, and operations have recovered.AI-graded · Global +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because App Platform - Global had degraded performance
  2. CLAUDE · SEV 3 · UNCLEAR · MEDIUM CONFIDENCE
    App Platform deployments and scaling failed for about 7.7 hours; already-running apps were unaffected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
1 update
  1. 17:09 UTC · resolved
    Between 04:34 and 12:15 UTC, customers experienced service interruptions affecting App Platform deployment operations. During this window, customers may have been unable to deploy new applications or scale existing deployments. Applications already running prior to the incident were unaffected and continued to operate normally. The disruption was caused by a software update that prevented application containers from starting on newly provisioned infrastructure nodes. Our Engineering team rolled back the update and restored the affected nodes. App Platform deployment and scaling operations have recovered and are operating normally. We sincerely apologize for any inconvenience this caused. If you continue to experience any issues, please open a support ticket and our team will be happy to assist you.
Source
Oct 11, 20261h 27mSEV 2
DNS Resolution for Managed KubernetesManaged Kubernetes clusters in multiple regions intermittently failed to resolve external domain names from 22:01 to 23:29 UTC on October 11. Applications on affected clusters were impacted. DigitalOcean's engineering team implemented a fix and resolved the issue; no cause was given in the updates.AI-graded · regional · Global +1
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Intermittent external DNS lookup failures hit apps on Managed Kubernetes clusters in multiple regions for about 90 minutes; not a full outage.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 22:01 UTC · investigating
    Our Engineering team is investigating an issue causing intermittent external DNS lookup failures for Managed Kubernetes clusters in multiple regions. Applications running on affected clusters may intermittently fail to resolve external domain names. We apologize for the inconvenience and will provide further updates as more information becomes available.
  2. 22:54 UTC · monitoring
    Our Engineering team has implemented a fix to address the intermittent external DNS lookup failures affecting Managed Kubernetes clusters in multiple regions. We are currently monitoring the results to ensure the issue is fully resolved. We will provide another update as soon as the issue is confirmed to be resolved.
  3. 23:29 UTC · resolved
    Our Engineering team has resolved the external DNS resolution failures affecting Managed Kubernetes across multiple regions. Applications running on Managed Kubernetes can now resolve external domain names. We sincerely apologize for any inconvenience this disruption may have caused to your operations. If you continue to experience problems, please open a ticket with our Support team: https://cloudsupport.digitalocean.com/s/
Source
Oct 5, 20261h 35mSEV 3
VPC Networking AvailabilityDigitalOcean VPC networking operations failed or were delayed from about 08:48 to 10:29 UTC on October 5, 2026. Creating or deleting VPC peerings, VPC-native DOKS clusters, Private Network Connections, routes and subnets was affected, and adding cluster members too. Existing VPC resources and connectivity stayed unaffected. A fix cleared pending operations and the incident was resolved.AI-graded · Global +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because VPC - Global had degraded performance
  2. CLAUDE · SEV 3 · GLOBAL · MEDIUM CONFIDENCE
    Creating and deleting VPC peerings, DOKS clusters, PNCs, routes and subnets failed or was delayed for about two hours; existing networking stayed up.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 10:38 UTC · identified
    Our Engineering team identified a disruption affecting VPC Networking operations that began at approximately 08:48 UTC. During this time, customers may have experienced delays or failures when creating or deleting VPC peerings, VPC Native DOKS clusters, or Private Network Connections (PNCs), as well as when adding cluster members. Creating routes and subnets may also have been affected. Operations are now returning to normal, and our Engineering team is monitoring the affected systems to ensure continued stability. Existing VPC resources and network connectivity remain unaffected. We will provide another update as soon as more information becomes available.
  2. 11:02 UTC · monitoring
    Our Engineering team has implemented a fix for the VPC Networking disruption. Customers should now be able to create and delete VPC peering connections, subnets, and routes as expected. Previously pending operations have been cleared, and VPC Networking operations are returning to normal. Our Engineering team is monitoring the affected systems to ensure continued stability and verify that operations remain healthy. We appreciate your patience and will provide another update once normal operation has been fully confirmed.
  3. 12:13 UTC · resolved
    Our Engineering team fully resolved the VPC Networking disruption as of 10:29 UTC. Customers can now create and delete VPC peering connections, subnets, and routes as expected. Following the recovery, we monitored the affected systems and confirmed that VPC Networking operations remain stable. We apologize for any inconvenience this disruption may have caused. If you continue to experience unexpected behavior, please open a ticket with our Support team for further assistance.
Source
Oct 3, 20260mSEV 2
A Network Disruption in BLR1 Region Impacted Multiple Products (Resolved)A networking disruption in DigitalOcean's BLR1 region, caused by failed upstream connectivity paths and resulting link saturation, degraded connectivity, latency and intermittent errors across multiple products from 11:59 to 13:02 UTC on October 3, 2026. Services returned to normal after routing was restored with upstream providers. Users still seeing issues were asked to open a support ticket.AI-graded · regional · Bangalore +9
Why this grade
  1. RULES · SEV 2
    Sev 2 because App Platform - Bangalore had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · HIGH CONFIDENCE
    Networking disruption in BLR1 caused degraded connectivity, latency and intermittent errors for apps, databases and control panel for about 71 minutes.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
1 update
  1. 14:51 UTC · resolved
    From 11:59 UTC to 13:02 UTC on October 3, 2026, a networking disruption in our BLR1 region affected multiple products, including Monitoring, App Platform, Managed Databases, Functions, Load Balancers, Spaces, and the Cloud Control Panel. During this period, some users experienced degraded connectivity, increased latency, or intermittent errors when accessing resources in the region. Multiple network paths operated by our upstream connectivity providers were unavailable, including redundant paths intended to maintain connectivity during a disruption. Traffic shifted to a remaining link with insufficient capacity to handle the full load, resulting in network saturation and the connectivity issues described above. Our Engineering and Network teams worked closely with our upstream providers to restore normal routing and connectivity. All affected services have since returned to normal operation. We apologize for the disruption and its impact on your work. If you continue to experience unexpected behavior, please open a support ticket so our team can investigate and assist you.
Source
Sep 16, 202611h 21mSEV 4
Support Portal Service DisruptionDigitalOcean's Support Portal was inaccessible and customers could not create or review support tickets from about 08:06 to 13:41 UTC on September 16, 2026, caused by an upstream third-party disruption. Customers were directed to a contact form as a workaround. Support responses were also delayed. The issue was resolved after the upstream provider applied a fix.AI-graded · Support Center
Why this grade
  1. RULES · SEV 4
    Sev 4 because Support Center had degraded performance
  2. CLAUDE · SEV 4 · UNCLEAR · HIGH CONFIDENCE
    Support Portal and ticket creation were inaccessible for hours due to a third-party disruption; core product and apps were not described as affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 09:48 UTC · investigating
    Our Support Portal is currently experiencing issues due to a third-party service disruption impacting our systems. During this time, customers may be unable to access the Support Portal or create new support tickets for their concerns. Existing support requests may also experience delayed responses from our Support team. As a workaround if you're unable to access the Support Portal or need to create a new support ticket, please submit your request via Support Contact form: https://www.digitalocean.com/company/contact/support. We apologize for the inconvenience and appreciate your patience while we work to resolve the issue. We'll provide another update as soon as we have more information.
  2. 14:07 UTC · monitoring
    The Support Portal and ticket creation are now accessible. Our upstream provider has applied a fix, and we've verified ticket creation and review are working as expected. We'll continue monitoring for the next 2 hours to confirm full stability and will post a final update once the incident is closed. If you're still unable to access the portal, please use our Support Contact form as a backup: https://www.digitalocean.com/company/contact/support We apologize for the disruption and appreciate your patience.
  3. 21:09 UTC · resolved
    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.
Source
Sep 9, 20261h 38mSEV 2
Power Degradation impacting GPU Performance in ATL1Part of DigitalOcean's ATL1 datacenter lost power redundancy, reducing available capacity. GPU Droplet workloads may have degraded during high utilization. No server outages were observed. Power redundancy was restored and the incident resolved about 1.5 hours after it started.AI-graded · one location · ATL1 +1
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · LOCAL · MEDIUM CONFIDENCE
    Reduced power capacity in part of ATL1 may have degraded some GPU workloads for about 1.5 hours; no server outages were observed.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 10:47 UTC · investigating
    We are investigating a power issue affecting part of our ATL1 datacenter. Redundant power systems are keeping servers online, and we have not observed any server outages. However, available power capacity is reduced, which may cause degraded performance for some GPU workloads, particularly during periods of high utilization. Our datacenter and infrastructure teams are working to restore full power redundancy. We will provide an update as more information becomes available. We apologize for the inconvenience and appreciate your patience.
  2. 11:32 UTC · monitoring
    The power issue affecting part of our ATL1 datacenter has been fully resolved. Power redundancy has been restored, and any potential customer impact has been mitigated. We will continue monitoring the environment to ensure continued stability.
  3. 12:25 UTC · resolved
    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.
Source
Aug 24, 202625h 50mSEV 2
Cloud Control Panel and APIAn auth database migration slowed an authorization query, causing retry storms and cascading timeouts. Control panel and API requests failed in two windows over about 3.5 hours on August 24-25, 2026. Under 2% of accounts were hit, with about 10% average failures. Droplets, networking and volumes were unaffected. Engineers restored service by consolidating traffic and disabling hedging. No data loss occurred.AI-graded · some customers · API +1
Why this grade
  1. RULES · SEV 1
    Sev 1 because the provider reported data loss or exposure
  2. CLAUDE · SEV 2 · SUBSET · HIGH CONFIDENCE
    Control panel and public API requests failed for under 2% of active accounts, peaking near 25% errors; Droplets and volumes stayed up.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
8 updates
  1. 17:14 UTC · investigating
    Our Engineering team is investigating an issue impacting the DigitalOcean public API and Cloud Control Panel. At this time, users will see elevated 5xx errors for all API requests, including things like creates for various products. Users may also be unable to access cloud.digitalocean.com. We are actively investigating the root cause and will provide updates as soon as more information becomes available. We apologize for the inconvenience and appreciate your patience.
  2. 18:33 UTC · investigating
    We are continuing to investigate the issue impacting the DigitalOcean public API and Cloud Control Panel. At this time, we are seeing some improvement in latency/error rates and some users may now be able to access the Cloud Control Panel. Serverless Inference users may currently experience 403 and 503 errors when making API requests or accessing affected services. We will continue to provide updates as more information becomes available. We apologize for the inconvenience and appreciate your patience.
  3. 19:14 UTC · monitoring
    Our Engineering team has implemented mitigation measures to address the issue affecting the DigitalOcean public API and Cloud Control Panel. We are seeing requests succeed, and users should now be able to access the Cloud Control Panel and issue/receive API requests normally. We are currently monitoring the situation to ensure that the service has returned to normal operation and remains stable. We appreciate your patience and will provide an update once the issue is fully confirmed as resolved.
  4. 22:27 UTC · investigating
    Our Engineering team is investigating a recurrence of the issue impacting the DigitalOcean public API and Cloud Control Panel. This issue does not impact our data plane (i.e. running droplets). Users may experience difficulties accessing the Cloud Control Panel, along with elevated latency and intermittent errors when accessing the public API or Cloud Control Plane. We are actively investigating the issue and working to restore normal service. We will continue to provide updates as more information becomes available. We apologize for the inconvenience and appreciate your patience.
  5. 00:54 UTC · monitoring
    Our Engineering team has implemented mitigation measures to address the issue impacting the DigitalOcean public API and Cloud Control Panel. We are seeing improvements, and users should now be able to access the Cloud Control Panel and use the public API normally. We are continuing to monitor the service to ensure it remains stable and will provide further updates as more information becomes available. We appreciate your patience and understanding.
  6. 16:30 UTC · monitoring
    Our Engineering team has continued to monitor the health of all services and has observed no recurrence of impact over the past 12+ hours. We will continue to monitor services for a short period to confirm stability before we mark this incident resolved. We understand the impact this incident had for DigitalOcean users and we will publish a postmortem on the status page to provide further details on root cause and mitigation.
  7. 19:04 UTC · resolved
    Our Engineering team has confirmed all services remain stable and we will now resolve this incident. Further details on root cause and mitigation will be provided in a postmortem via this status page for users interested in learning more. Thank you for your patience throughout this incident. If you continue to experience any issues, please reach out to Support from within your account
  8. 18:44 UTC · postmortem
    ## 1. What happened 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: 1. 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. 1. 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. 1. 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. |
PostmortemSource
Aug 23, 20269h 22mSEV 3
Managed Databases CreationUsers could not create Managed Database clusters in NYC1 and NYC3 via the control panel or API from about 05:11 to 14:33 UTC on 23 August. Engineering implemented fixes and monitored stability before resolving. Existing clusters were not described as affected.AI-graded · regional · NYC1 +4
Why this grade
  1. RULES · SEV 2
    Sev 2 because Managed Databases - NYC1 had degraded performance
  2. CLAUDE · SEV 3 · REGIONAL · HIGH CONFIDENCE
    Creating Managed Database clusters failed in NYC1 and NYC3 for about nine hours; existing clusters were not described as affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
4 updates
  1. 05:11 UTC · investigating
    Our Engineering team is investigating an issue with our Managed Database product. At this time, users may experience errors while creating clusters, both via Cloud Control Panel and API requests. We apologize for the inconvenience and will share an update once we have more information.
  2. 07:06 UTC · investigating
    We continue to investigate an issue affecting DigitalOcean Managed Databases cluster creation across multiple regions. During this time, users may experience errors when creating Managed Database clusters via the Cloud Control Panel or API. Our engineering team is implementing a mitigation and working to restore normal provisioning. We will provide another update as soon as more information is available.
  3. 11:30 UTC · monitoring
    Our Engineering team has implemented the necessary fixes affecting Managed Database cluster creation in the NYC3 and NYC1 regions. Users should now be able to create new Managed Database clusters.   We are currently monitoring the situation to ensure that the service has returned to normal operation and remains stable. We appreciate your patience and will provide an update once the issue is fully confirmed as resolved.
  4. 14:33 UTC · resolved
    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/
Source
Aug 21, 20261h 53mSEV 2
Container Registry and Spaces AccessibilityDigitalOcean reported that Container Registry image push and pull failed in some regions, and Spaces buckets were hard to reach via the Cloud Control Panel, starting 12:59 UTC on 21 August 2026. A fix was applied around 13:06 UTC and the incident was resolved by 14:52 UTC. The text does not give a root cause.AI-graded · regional · Global +2
Why this grade
  1. RULES · SEV 3
    Sev 3 because Container Registry - Global had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Container Registry pushes and pulls failed and Spaces control panel access broke in some regions for about two hours.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 12:59 UTC · investigating
    Our Engineering team is currently investigating reports of an issue affecting Container Registry and Spaces buckets in some regions. During this time, customers may experience failures when pushing or pulling container images. Additionally, customers may experience issues accessing Spaces via the Cloud Control Panel, where the page may display "Looks like something went wrong…" Our Engineering team is actively investigating the issue and treating it with priority. We will provide another update as soon as more information becomes available.
  2. 13:06 UTC · monitoring
    Our Engineering team has identified the issue affecting Container Registry and Spaces buckets, and a fix has been applied. Spaces accessibility via the Cloud Control Panel should now be restored, and pushing and pulling container images should be back to normal. We are continuing to monitor the results to ensure the issue has been fully resolved and will provide another update once we've confirmed normal service has been restored.
  3. 14:52 UTC · resolved
    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.
Source
Aug 19, 20268h 25mSEV 2
Major Service Interruption in MKC1An MKC1 region incident affected multiple racks and nodes from about 11:10 to 19:34 UTC on 19 August. GPU Droplets and GPU inference endpoints stayed offline or unreachable, and some DOKS GPU nodes stayed NotReady. Control plane, CPU Droplets, databases and storage were restored by 18:59. The cause was a facility equipment issue; full GPU recovery was still pending at resolution.AI-graded · one location · MKC1 +2
Why this grade
  1. RULES · SEV 1
    Sev 1 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · LOCAL · MEDIUM CONFIDENCE
    GPU Droplets and GPU-backed inference in MKC1 went offline across multiple racks for about eight hours; CPU services and the control plane recovered.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
5 updates
  1. 11:10 UTC · investigating
    Our Engineering team is currently investigating an issue in the MKC1 region affecting multiple racks and nodes. During this time, customers may experience disruptions to GPU workloads, and Kubernetes (DOKS) worker nodes may enter a NotReady state. Our team is actively working to restore connectivity and bring impacted nodes back online. If you continue to experience issues, please open a support ticket from within your account.
  2. 12:22 UTC · identified
    We have identified the root cause of the issue in the MKC1 region affecting multiple racks and nodes. Our Engineering team is actively implementing remediation steps to restore connectivity and bring the impacted nodes back online. During this time, customers may continue to experience disruptions to GPU workloads and Serverless Inference. Kubernetes (DOKS) worker nodes may also remain in a NotReady state, and customers may be unable to reach Kubernetes API endpoints or perform cluster-management operations in affected clusters. We will provide another update as soon as we have more information.
  3. 15:28 UTC · identified
    Our Engineering team continues to work on the issue affecting the MKC1 region. We are actively working to restore connectivity and bring the impacted nodes back online. We will provide another update as soon as we have more information.
  4. 18:59 UTC · monitoring
    At this time, the regional control plane is fully healthy. CPU Droplets, Managed databases, Load balancers, Block storage and Spaces are operating normally. Droplet create, resize and other management operations are working. Kubernetes (DOKS) control planes are reachable. Our teams are continuing to work with the facility to restore all equipment. GPU Droplets in MKC1 remain offline or unreachable. DOKS GPU worker nodes may remain NotReady, and GPU-backed inference endpoints in this region may be unavailable. We will monitor the regional control plane for a short time and then resolve this incident. GPU customers will receive personalized updates with more information in lieu of this status page. If you have questions about your affected resources, contact support and reference this incident.
  5. 19:34 UTC · resolved
    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.
Source
Aug 13, 20260mSEV 2
Volume Attach/Detach events in FRA1From 09:50 to 14:30 UTC on Aug 13, FRA1 customers had delays or failures attaching and detaching Block Storage Volumes on Droplets and Managed Kubernetes clusters. Operations were restored, though some residual cleanup of Kubernetes volume attachments is still in progress.AI-graded · regional · FRA1 +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Volumes - FRA1 had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Volume attach and detach operations failed or were delayed in FRA1 for about five hours; other regions were not reported affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
1 update
  1. 14:59 UTC · resolved
    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.
Source
Aug 8, 20266h 03mSEV 2
Account Registration, Droplets, and Related ServicesAcross multiple regions for about six hours, new account registration, Droplet creation, Reserved IPs, snapshots and backups, DOKS cluster operations, autoscaling, and the Droplet console failed. GenAI services were affected, and database clusters got stuck in Creating. The provider fixed the issue and resolved it after monitoring.AI-graded · regional · Global +4
Why this grade
  1. RULES · SEV 2
    Sev 2 because Managed Databases - Global had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Account signup, Droplet creation, snapshots and DOKS operations failed across multiple regions for about 6 hours; running workloads were not described as down.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
6 updates
  1. 18:57 UTC · investigating
    Our Engineering team is currently investigating reports of an issue affecting new account registration, Reserved IPs, Snapshots, Droplets and Droplet-based services across multiple regions. During this time, customers may be unable to create new accounts, create Droplets, allocate Reserved IPs, or perform Automated Backups and Snapshots operations. Droplet Autoscale scaling operations and DOKS cluster operations are also affected. Our Engineering team is actively investigating the issue and we will provide another update as soon as more information becomes available.
  2. 19:38 UTC · investigating
    Our Engineering team is continuing to investigate reports of an issue affecting new account registration, Reserved IPs, Snapshots, Droplets and Droplet-based services across multiple regions. During this time, customers may be unable to create new accounts, create Droplets, allocate Reserved IPs, or perform Automated Backups and Snapshots operations. Droplet Autoscale scaling operations and DOKS cluster operations are also affected. Further investigation has found that GenAI services are also affected due to this issue, customers may also be unable to access the Droplet console, and Database clusters may be stuck in a "Creating" state. Our Engineering team is actively investigating the issue and we will provide another update as soon as more information becomes available.
  3. 20:02 UTC · identified
    Our Engineering team has identified the root cause of the issue affecting new account registration, Droplets, Reserved IPs, Snapshots, and DOKS clusters across multiple regions. Customers may experience the following: Unable to create new accounts Unable to create Droplets Unable to allocate Reserved IPs Failures with Automated Backups and Snapshots operations Droplet Autoscale scaling operations not working as expected DOKS cluster operations failing GenAI services impacted Unable to access the Droplet console Database clusters stuck in a "Creating" state Our Engineering team is working on implementing a fix and we will provide another update as soon as more information becomes available.
  4. 22:02 UTC · identified
    Our Engineering team continues to work on implementing and rolling out a fix for the issue affecting multiple services across multiple regions, including new account registration, Droplets, Reserved IPs, Automated Backups and Snapshots, Droplet Autoscale, DOKS clusters, GenAI services, the Droplet console, and Database cluster creation. Customers may continue to experience the previously reported service disruptions while remediation efforts remain in progress. We will provide another update as soon as more information becomes available.
  5. 00:31 UTC · monitoring
    Our Engineering team has implemented a fix for the issue affecting new account registration, Droplets, Reserved IPs, Snapshots, and DOKS clusters across multiple regions, and is currently monitoring the situation. At this time, customers should no longer experience errors with: New account registration Droplet creation Reserved IP allocation Automated Backups and Snapshots operations Droplet Autoscale scaling operations DOKS cluster operations GenAI services Access to the Droplet console Database cluster creation We will continue to monitor the situation to ensure that all services are stable and functioning as expected. We will post an update as soon as the issue is fully resolved.
  6. 01:01 UTC · resolved
    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.
Source
Aug 6, 20262h 04mSEV 2
Functions on App PlatformFunctions on App Platform hit an SSL error when App Platform forwarded requests to Functions, causing 504 errors on Functions endpoints and build/deploy failures. Starting 19:01 UTC on 2026-08-06, a fix was deployed around 20:02 and the incident was resolved at 21:05 UTC.AI-graded · some customers · Global +2
Why this grade
  1. RULES · SEV 2
    Sev 2 because App Platform - Global had degraded performance
  2. CLAUDE · SEV 2 · SUBSET · HIGH CONFIDENCE
    Functions on App Platform returned 504 errors from an SSL forwarding fault and builds/deploys failed for about two hours; isolated to App Platform Functions.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 19:01 UTC · investigating
    Our Engineering team is investigating an issue impacting Functions on App Platform. During this time, users may experience build/deploy failures for Functions components, and requests to Functions endpoints may fail with a 504 error, caused by an SSL error when App Platform attempts to forward requests to Functions. This issue currently appears to be isolated to Functions deployed within App Platform. We apologize for the inconvenience and will share an update once we have more information.
  2. 20:02 UTC · monitoring
    Our Engineering team has implemented a fix for the issue affecting Functions on App Platform. Functions builds/deploys and requests to Functions endpoints should now be completing successfully. We are currently monitoring the situation to ensure the service has returned to normal operation and remains stable. We apologize for the inconvenience and will provide a further update once the incident is confirmed resolved.
  3. 21:05 UTC · resolved
    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.
Source
Aug 6, 20260mSEV 2
Multiple Services AvailabilityFrom about 06:42 to 09:08 UTC on Aug 6, write operations failed across DigitalOcean services including Managed Databases, DOKS, Cloud Firewalls, DNS, Spaces, Volumes, and event processing. Customers could not change configuration or provision or scale resources, and event processing was delayed or failed. Services recovered, and the provider gave no cause in the update.AI-graded · Global +7
Why this grade
  1. RULES · SEV 2
    Sev 2 because DNS had degraded performance
  2. CLAUDE · SEV 2 · GLOBAL · MEDIUM CONFIDENCE
    Write operations failed across several DigitalOcean services for about two and a half hours; reads and running workloads were not described as affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
1 update
  1. 16:33 UTC · resolved
    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.
Source
Aug 4, 20265h 29mSEV 4
Spaces Cold Storage BillingSpaces Cold Storage customers saw incorrect daily usage and current invoice values from about 16:13 to 21:42 UTC on August 4, 2026. A billing data sync error caused it. The team fixed the sync and reported accurate usage reporting restored. Storage operations were not described as affected.AI-graded · some customers · Global +2
Why this grade
  1. RULES · SEV 4
    Sev 4 because Billing had degraded performance
  2. CLAUDE · SEV 4 · SUBSET · MEDIUM CONFIDENCE
    Cold storage customers saw incorrect daily usage and invoice values for about five hours; storage itself was not reported affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
4 updates
  1. 16:13 UTC · investigating
    Our Engineering team is investigating an issue affecting Spaces Cold Storage billing. During this time, customers with cold storage buckets may see incorrect values reflected in their daily usage and current invoices. We apologize for the inconvenience and are actively working to resolve the issue. We will provide an update as soon as more information becomes available.
  2. 18:52 UTC · identified
    Our Engineering team has identified the issue affecting Spaces Cold Storage billing. The team is actively working on a fix to resolve the issue. We apologize for the inconvenience and will provide another update as soon as more information becomes available.
  3. 20:44 UTC · monitoring
    Our Engineering team has implemented a fix for the issue affecting Spaces Cold Storage billing and is currently monitoring the situation. Customers with cold storage buckets should no longer see incorrect values reflected in their daily usage and current invoices. We will post an update as soon as the issue is fully resolved.
  4. 21:42 UTC · resolved
    As of 21:06 UTC, our Engineering team has resolved the issue affecting Spaces Cold Storage billing. An error in our billing processing system caused incorrect values to be reflected in daily usage and current invoices for customers with cold storage buckets. Our team identified and corrected an issue with the billing data sync, ensuring accurate usage reporting. If you continue to experience any issues, please open a ticket with our Support team. We apologize for any inconvenience this may have caused.
Source
Aug 3, 20264h 02mSEV 3
Cloud Control Panel AccessSome customers saw intermittent errors and 'mTLS verification failed' messages when accessing the Cloud Control Panel from 09:36 to 13:30 UTC on August 3. Expired internal certificates were renewed and access was restored. Customer apps were not reported affected.AI-graded · some customers · Cloud Control Panel
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 3 · SUBSET · HIGH CONFIDENCE
    Some customers got intermittent errors and mTLS failures in the Cloud Control Panel for about four hours; apps and APIs were not reported affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 13:58 UTC · investigating
    Beginning at 09:36 UTC on August 3, some customers may experience intermittent errors when accessing the DigitalOcean Cloud Control Panel, including an "mTLS verification failed" message. Our engineering team is actively investigating. We apologise for the inconvenience this may have caused. We will provide another update as soon as more information is available. If you have any questions related to this issue, please send us a ticket from your cloud support page. https://cloudsupport.digitalocean.com/s/createticket
  2. 16:39 UTC · monitoring
    We have implemented mitigation for the issue causing some customers to experience intermittent errors when accessing the DigitalOcean Cloud Control Panel. We are seeing recovery and are monitoring the service closely. We will provide another update once we have confirmed the issue is fully resolved
  3. 17:59 UTC · resolved
    Between 09:36 and 13:30 UTC on August 3, some customers experienced intermittent errors while accessing the DigitalOcean Cloud Control Panel. We renewed the affected internal certificates and restored access. The issue is resolved, and the Cloud Control Panel is operating normally. We apologize for the disruption.
Source
Jul 29, 202612h 19mSEV 2
Response Degradation Impacting Kimi-K3Kimi-K3 on DigitalOcean's Agentic Inference Cloud returned empty or broken responses, including repeated characters, from July 29 17:56 UTC until resolved July 30 06:15 UTC. Engineering identified and fixed the issue; the update gives no further cause detail.AI-graded · some customers · Model Services +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Model Services had degraded performance
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
    Kimi-K3 model responses were empty or broken, including repeated characters, for about 12 hours; other services were not described as affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 17:56 UTC · investigating
    We are currently investigating this issue.
  2. 21:41 UTC · investigating
    Our Engineering team is investigating reports of empty or broken responses impacting Kimi-K3. At this point, users may experience degraded response quality, specifically empty or broken outputs (including repeated characters), when querying the Kimi-K3 service. We apologize for the inconvenience and will share an update once we have more information.
  3. 06:15 UTC · resolved
    Our Engineering team has resolved the issue causing empty or broken responses from Kimi-K3. If you continue to experience any problems, please open a ticket with our Support team. We apologize for any inconvenience this may have caused.
Source
Jul 27, 202620h 53mSEV 2
Agent Platform Requests Returning HTTP 500 ErrorsAgent Platform requests returned HTTP 500 errors for about 21 hours; the update text does not say how many customers were hit.AI-graded · Agent Runtime +1
Why this grade
  1. RULES · SEV 1
    Sev 1 because Agent Runtime had a partial outage
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
    Agent Platform requests returned HTTP 500 errors for about 21 hours; the update text does not say how many customers were hit.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 18:31 UTC · investigating
    We are currently investigating this issue.
  2. 19:44 UTC · identified
    The issue has been identified and a fix is being implemented.
  3. 15:24 UTC · resolved
    This incident has been resolved.
Source
Jul 24, 20262h 06mSEV 3
Network Connectivity from India to NYCUsers in India on Airtel and BSNL reported latency, packet loss, and intermittent connectivity to DigitalOcean NYC resources. The provider later said impact was limited to Airtel users, from about 07:46 to 10:24 UTC, and that the cause was an internal Airtel network issue, not DigitalOcean's. The issue is resolved.AI-graded · some customers · NYC1 +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Networking - NYC1 had degraded performance
  2. CLAUDE · SEV 3 · SUBSET · MEDIUM CONFIDENCE
    Some users in India on Airtel saw latency and packet loss reaching NYC resources; the provider attributes the cause to Airtel's network.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 10:36 UTC · identified
    We have noticed ​​​​​​​network connectivity issues affecting some users connecting from India to resources in the NYC region. Based on our current investigation, users on Airtel and BSNL have reported increased latency, packet loss, or intermittent connectivity. We apologize for the inconvenience and will provide an update as soon as more information becomes available.
  2. 11:45 UTC · monitoring
    We are observing improvements in network connectivity for users in India accessing resources in our NYC region. Our team is monitoring the situation to ensure that the service has returned to normal operation and remain stable. We appreciate your patience and will provide an update once the issue is fully confirmed as resolved.
  3. 12:42 UTC · resolved
    Between 07:46  UTC & 10:24 UTC today, some users in India accessing resources in the NYC region may have experienced connectivity issues. The impact was limited to users using Airtel as their ISP. Our investigation determined that the issue was caused by an internal network issue within Airtel and was not related to DigitalOcean network. The connectivity issue now appears to be resolved, and users should no longer experience problems accessing their resources. We apologize for any inconvenience this may have caused. However, if you continue to experience any connectivity issues, please don't hesitate to open a support ticket for further investigation; we'll be happy to assist you further.
Source
Jul 23, 20261h 20mSEV 2
Llama-4-Maverick Model AvailabilityThe llama-4-maverick model returned HTTP 500 errors on Serverless Inference for about 80 minutes; other models were not described as affected.AI-graded · some customers · Inference +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Inference had degraded performance
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
    The llama-4-maverick model returned HTTP 500 errors on Serverless Inference for about 80 minutes; other models were not described as affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
2 updates
  1. 11:16 UTC · investigating
    Our Engineering team is currently investigating an issue where the llama-4-maverick model is unavailable. Users may experience HTTP 500 errors while using this model with Serverless Inference. We apologize for the inconvenience. Our Engineering team is working with high priority to resolve the issue. Thank you for your patience and understanding.
  2. 12:37 UTC · resolved
    This incident has been resolved.
Source
Jul 22, 20262h 52mSEV 2
Gradient AI Serverless Inference Requests Timing Out for qwen3.5-397b-a17bServerless inference requests for one model timed out for about three hours; other models were not described as affected.AI-graded · some customers · Inference +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Inference had degraded performance
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
    Serverless inference requests for one model timed out for about three hours; other models were not described as affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
2 updates
  1. 16:50 UTC · investigating
    We are currently investigating this issue.
  2. 19:42 UTC · resolved
    This incident has been resolved.
Source
Jul 19, 20265h 41mSEV 3
Block Storage Volume NYC1, NYC3, SGP1, SYD1 and BLR1Droplets in NYC1, NYC3, SGP1, SYD1 and BLR1 could not attach Block Storage volumes from about 09:51 to 15:32 UTC on July 19, 2026. Engineering identified the root cause, deployed a fix at 14:52, and resolved the incident after monitoring.AI-graded · regional · BLR1 +9
Why this grade
  1. RULES · SEV 2
    Sev 2 because Volumes - BLR1 had degraded performance
  2. CLAUDE · SEV 3 · REGIONAL · MEDIUM CONFIDENCE
    Volume attachment to Droplets failed in five regions for about six hours; existing volumes and other operations were not described as affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
5 updates
  1. 09:51 UTC · investigating
    Our Engineering team is investigating an issue with attaching volume to the droplets in the NYC1, NYC3, SGP1, SYD1 and BLR1 regions. During this time you may experience an issue with attaching volume to the Droplet(s). We apologize for the inconvenience and will share an update once we have more information.
  2. 13:34 UTC · investigating
    We are continuing to investigate this issue.
  3. 13:36 UTC · investigating
    We are continuing to investigate this issue.
  4. 14:52 UTC · monitoring
    Our Engineering team has identified the root cause of the issue preventing volume attachments to Droplets in NYC1, NYC3, SGP1, SYD1, and BLR1 and has successfully implemented a fix. You should now be able to attach volumes to your Droplet(s) without encountering any further errors or issues. We are actively monitoring the situation to ensure the fix remains effective and will provide another update once the issue has been fully resolved.
  5. 15:32 UTC · resolved
    Our Engineering team has confirmed that the issue regarding volume attachment to Droplets in the NYC1, NYC3, SGP1, SYD1, and BLR1 regions has been fully resolved, and all services are now operating normally. If you continue to experience any issues, please contact our Support team by opening a ticket. We apologize for any inconvenience caused.
Source
Jul 19, 20262h 54mSEV 2
Networking in BLR1Droplets in the BLR1 region had outbound network connectivity problems, with timeouts reaching external endpoints, from about 06:57 to 09:52 UTC on 19 July 2026. The cause was an upstream network connectivity issue; engineers worked with upstream providers and implemented a fix, and the incident was resolved.AI-graded · regional · BLR1 +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Networking - BLR1 had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · HIGH CONFIDENCE
    Outbound network traffic from Droplets in BLR1 timed out or failed for about three hours; other regions were not reported affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
4 updates
  1. 06:57 UTC · investigating
    We are currently investigating an issue affecting outbound network traffic for Droplets in the BLR1 region. Customers may experience timeout errors or connectivity issues when attempting to reach external services. Our Engineering team is actively investigating the issue and working to identify the root cause. We will provide additional updates as soon as more information becomes available.
  2. 08:27 UTC · identified
    Our Engineering team has identified an issue affecting upstream network connectivity for Droplet-based services in the BLR1 region and is actively working with the relevant upstream providers to implement a resolution. Customers may continue to experience intermittent timeouts or connectivity issues when attempting to reach external endpoints from Droplets in BLR1. We will provide another update once the issue has been fully resolved or when additional information becomes available.
  3. 09:31 UTC · monitoring
    Our engineering team has implemented the necessary fixes affecting upstream network connectivity for Droplet-based services in the BLR1 region. Users should now be able to connect to the external endpoints from Droplets in BLR1. We are currently monitoring the situation to ensure that the service has returned to normal operation and remain stable. We appreciate your patience and will provide an update once the issue is fully confirmed as resolved.
  4. 09:52 UTC · resolved
    Our engineering team has resolved the outbound network connectivity issue in the BLR1 region. If you continue to experience problems, please open a ticket with our support team. We apologize for any inconvenience.
Source
Jul 16, 20263h 45mSEV 2
Reserved IP routing in TOR1Reserved IP routing in DigitalOcean's TOR1 region failed, so inbound and outbound traffic to and from Reserved IPs there broke from about 13:40 to 17:25 UTC on July 16, 2026. Engineers identified the cause, deployed a fix, and confirmed resolution. Detaching and reassigning the Reserved IP was offered as a workaround.AI-graded · regional · Reserved IP +2
Why this grade
  1. RULES · SEV 2
    Sev 2 because Networking - TOR1 had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · HIGH CONFIDENCE
    Inbound and outbound traffic on Reserved IPs failed in the TOR1 region for about 4 hours; other regions were not reported affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
4 updates
  1. 13:39 UTC · investigating
    Our Engineering team is investigating an issue affecting Reserved IP routing in the TOR1 region. The issue is causing inbound and outbound traffic to and from Reserved IPs in TOR1 to fail. In the meantime, detaching and reassigning the Reserved IP to the Droplet may restore connectivity. We recommend trying this workaround if you are experiencing issues with your Reserved IP in TOR1. Our engineering team is actively investigating the root cause and working towards a resolution. We will provide updates as more information becomes available.
  2. 15:30 UTC · identified
    Our Engineering team has identified the cause of the issue affecting Reserved IP routing in the TOR1 region, which was causing inbound and outbound traffic to and from Reserved IPs in TOR1 to fail. Detaching and reassigning the Reserved IP to the Droplet may restore connectivity in the meantime. We recommend trying this workaround if you are still experiencing issues with your Reserved IP in TOR1. Our engineering team is now working on implementing a fix. We will provide updates as more information becomes available.
  3. 17:01 UTC · monitoring
    Our Engineering team has implemented a fix for the issue affecting Reserved IP routing in the TOR1 region, and we are currently monitoring the results. Inbound and outbound traffic to and from Reserved IPs in TOR1 should now be restored. If you reassigned your Reserved IP as a workaround and are still experiencing issues, please reach out to our support team. We will continue to monitor the situation closely and provide a further update once we have confirmed the issue is fully resolved.
  4. 17:24 UTC · resolved
    Our Engineering team has confirmed that the underlying issue affecting Reserved IP routing in the TOR1 region has been fully resolved, and services are now operating normally. If you continue to experience any issues, please contact our Support team by opening a ticket. We apologize for any inconvenience caused.
Source
Jul 13, 20262d 2hSEV 2
Serverless Inference - Gemma4 Latency Issues Causing Timeouts & Slow ResponsesGemma 4 model requests on DigitalOcean Serverless and Dedicated Inference suffered high latency and timeouts from July 13 to July 15, 2026. A backend configuration issue was the root cause. A fix was deployed and response times returned to baseline by the July 15 resolution.AI-graded · some customers · Inference +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Inference had degraded performance
  2. CLAUDE · SEV 2 · SUBSET · HIGH CONFIDENCE
    Gemma 4 inference on Serverless and Dedicated Inference had severe latency and timeouts for about two days; other models were not described as affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
5 updates
  1. 19:04 UTC · identified
    We are currently experiencing an issue where customers using the Gemma 4 model on our Serverless Inference and Dedicated Inference platforms may experience severe latency or request timeouts. Our engineering team has identified a backend configuration issue as the root cause, which is temporarily degrading performance. We are actively working on a fix to restore normal response times and will provide another update as soon as the mitigation is in place
  2. 22:24 UTC · monitoring
    A fix has been deployed to resolve the backend configuration issue. We are closely monitoring system performance to ensure full recovery and normal response times for all Gemma 4 inference workflows.
  3. 11:07 UTC · identified
    We are currently experiencing an issue affecting customers using the Gemma 4 model on our Serverless Inference platform. Customers may experience significantly increased latency or request timeouts. Our Engineering team has identified a backend configuration issue as the root cause, which is temporarily impacting model performance. Please be assured that our Engineering team is actively working on a fix and is treating this issue with high priority. We sincerely apologise for any inconvenience this may have caused and appreciate your patience and understanding. If you have any further questions, please create a support ticket so that we can investigate your specific case further.
  4. 10:06 UTC · monitoring
    A fix has been deployed to resolve the issue. We are closely monitoring system performance to ensure full recovery and normal response times for all Gemma 4 inference workflows.
  5. 21:46 UTC · resolved
    The deployed fix has successfully restored full functionality, and our monitoring shows that system performance has completely stabilized. Response times for all Gemma 4 inference workflows have returned to normal baseline levels. We will continue to track platform stability moving forward to ensure long-term reliability. We apologize for any disruption this may have caused to your workflows and appreciate your patience throughout the recovery process.
Source
Jul 9, 202628h 56mSEV 2
Kubernetes Deployments in NYC1DigitalOcean reported intermittent DNS timeouts and NodeNotReady events affecting a small number of DOKS clusters in NYC1 from July 9 to July 11, 2026. The cause was shared-CPU worker nodes; the provider recommends dedicated CPU pools and more CoreDNS replicas, and asks affected users to open tickets if issues persist.AI-graded · some customers · NYC1 +1
Why this grade
  1. RULES · SEV 3
    Sev 3 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
    Intermittent DNS failures and NodeNotReady events hit application workloads on a small number of Kubernetes clusters in NYC1 for about two days.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 20:31 UTC · investigating
    Our Engineering team is investigating an issue affecting Kubernetes deployments in NYC1. Users may see intermittent DNS failures and NodeNotReady events from application workloads during this time. We apologize for the inconvenience, we'll share new information on this page as soon as it is available.
  2. 01:18 UTC · monitoring
    The issue affecting Kubernetes deployments in NYC1 has subsided. Workloads should now be functioning normally. Our Engineering team is continuing to monitor the affected systems to confirm full resolution. We'll update this page if any further action is needed. We apologize for the inconvenience this may have caused.
  3. 01:27 UTC · resolved
    The issue affecting Kubernetes deployments in the NYC1 region has been resolved. Our investigation found intermittent DNS timeouts affecting a small number of DOKS clusters, with affected worker nodes running on shared-CPU Droplets. This is a documented limitation for latency-sensitive cluster DNS workloads such as CoreDNS. The affected clusters are currently functional. To reduce the risk of recurrence, we recommend running CoreDNS on non-shared/dedicated CPU node pools and using sufficient CoreDNS replicas. If you continue to see DNS failures or NodeNotReady events, please open a support ticket so we can investigate that cluster specifically.
Source
Jul 4, 20262h 40mSEV 2
Limited access to Deepseek V4 Pro modelDigitalOcean's Deepseek V4 Pro model in Serverless Inference and Agent Platform returned error 429 messages to users from about 22:13 to 00:53 UTC on July 4-5, 2026. Engineers implemented a fix, then confirmed full resolution. The cause was not stated in the updates.AI-graded · some customers · Inference +3
Why this grade
  1. RULES · SEV 1
    Sev 1 because Inference had a partial outage
  2. CLAUDE · SEV 2 · SUBSET · HIGH CONFIDENCE
    Requests to the Deepseek V4 Pro model returned error 429 for about two and a half hours; other models were not described as affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 22:13 UTC · investigating
    Our Engineering team is investigating reports of an incident affecting the Deepseek V4 Pro model in Serverless Inference and Agent Platform. Users may experience errors when attempting to use this model, specifically receiving error 429 messages. We apologize for the inconvenience and are working to resolve the issue as soon as possible. We will provide an update once we have more information.
  2. 23:18 UTC · monitoring
    Our Engineering team has implemented a fix for the issue with the Deepseek V4 Pro model in Serverless Inference and Agent Platform. The model should now be operational, and users should no longer receive error 429 messages when attempting to use it. We are currently monitoring the situation to ensure the fix is successful and the model is functioning as expected. We will post an update if any further issues arise. If you continue to experience problems, please open a ticket with our Support team. We apologize for any inconvenience this may have caused.
  3. 00:53 UTC · resolved
    Our Engineering team has confirmed that the issue with the Deepseek V4 Pro model in Serverless Inference and Agent Platform has been fully resolved. The model is now operational, and users should be able to use it without experiencing any errors. If you continue to experience any problems, please open a ticket with our Support team. We apologize for any inconvenience this may have caused and appreciate your patience.
Source
Jul 4, 202627mSEV 3
Droplet Actions in NYC3DigitalOcean's NYC3 region had disruptions for customers performing actions on Droplets, and some attempts to create Droplets errored, starting around 12:38 UTC. Engineering implemented a fix and later confirmed full resolution. No cause was given in the updates.AI-graded · one location · NYC3 +2
Why this grade
  1. RULES · SEV 3
    Sev 3 from the incident title (no components listed)
  2. CLAUDE · SEV 3 · LOCAL · MEDIUM CONFIDENCE
    Droplet actions and some Droplet creation failed in the NYC3 region for about two and a half hours; other regions were not reported affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
2 updates
  1. 14:42 UTC · monitoring
    Our Engineering team has implemented a fix to address the issue affecting Droplets in the NYC3 region. The issue, which began at 12:38 UTC, caused disruptions to customers attempting to perform actions on their Droplets in the NYC3 region. During this time, customers may also have experienced errors when trying to create Droplets in this region. We are actively monitoring the situation to ensure the fix remains effective and will provide another update once the issue has been fully resolved.
  2. 15:10 UTC · resolved
    Our Engineering team has confirmed that the issue impacting Droplets in the NYC3 region has been fully resolved. Users can now perform actions on their Droplets or create new Droplets in this region without any issues. We appreciate your patience while we worked to resolve this issue. If you continue to experience any problems, please open a support ticket from your account so our team can investigate further.
Source
Jul 2, 202610h 16mSEV 3
Managed Database ClustersUsers faced delays creating, scaling, forking and restoring Standard MySQL, Standard PostgreSQL, OpenSearch, Kafka and Valkey clusters via the control panel or API, starting July 2 22:04 UTC. The issue was fixed and resolved July 3 at 08:20 UTC. No root cause was given.AI-graded · Global +2
Why this grade
  1. RULES · SEV 2
    Sev 2 because Managed Databases - Global had degraded performance
  2. CLAUDE · SEV 3 · GLOBAL · MEDIUM CONFIDENCE
    Creating, scaling, forking and restoring managed database clusters was delayed for about 10 hours; running databases were not described as affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
4 updates
  1. 22:04 UTC · investigating
    Our engineering team is investigating an issue affecting Managed Database Clusters. Currently, users may encounter delays when creating/scaling/forking and restoring Standard MySQL, Standard PostgreSQL, OpenSearch, Kafka, and Valkey clusters through the Cloud Control Panel or API. We apologize for the inconvenience and will provide further updates as soon as more information is available.
  2. 02:28 UTC · investigating
    Our engineering team is still investigating the issue affecting Managed Database Clusters. Users may still encounter delays creating/scaling/forking/restoring the aforementioned Managed Database Clusters. We are working to resolve this as soon as possible. we apologize for the inconvenience. We will post an update here once we have more information.
  3. 06:08 UTC · monitoring
    Our engineering team has implemented a fix to resolve the issue with Managed Database Clusters and is monitoring the situation. We will post an update as soon as the issue is fully resolved.
  4. 08:20 UTC · resolved
    Our engineering team has resolved the issue with Managed Database Clusters. All database systems should now be operating normally. If you continue to experience problems, please open a ticket with our support team. We apologize for any inconvenience.
Source
Jul 1, 20264h 53mSEV 2
DNS Lookup Failures for Managed DatabaseDigitalOcean reported intermittent DNS lookup failures for Managed Database hostnames from Managed Kubernetes in the FRA1 region, starting about 11:35 UTC and resolved around 16:28 UTC on 1 July 2026. Customers saw intermittent connectivity issues to their databases. The provider said connectivity stayed stable after the fix; no root cause was given in the updates.AI-graded · regional · FRA1 +3
Why this grade
  1. RULES · SEV 2
    Sev 2 because DNS had degraded performance
  2. CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
    Intermittent DNS lookup failures hit Managed Kubernetes to Managed Database connections in FRA1 for about five hours; other regions were not mentioned.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 11:35 UTC · investigating
    As of 06:39 UTC, our Engineering team is investigating reports of intermittent DNS lookup failures for Managed Database hostnames from Managed Kubernetes, primarily affecting connections from Managed Kubernetes to Managed Database hostnames. At this point, customers in the FRA1 region may experience intermittent connectivity issues. We apologize for the inconvenience and will share an update once we have more information.
  2. 12:15 UTC · investigating
    We are continuing to investigate this issue.
  3. 16:28 UTC · resolved
    The intermittent DNS lookup failures between Managed Kubernetes and Managed Database hostnames in the FRA1 region have been resolved for now but please let us know if you see the issue again. Connectivity has remained stable, and all systems are operating normally. 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.
Source
Jul 1, 20262h 15mSEV 4
Droplet ResizeFor about two hours, the Downscale Anytime option for resizing Droplets was unavailable or unresponsive in the Cloud Control Panel. DigitalOcean said resizes could be done via the API as a workaround. A fix was deployed and the issue was confirmed resolved, with the affected option working again.AI-graded · some customers · Cloud Control Panel
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 4 · SUBSET · HIGH CONFIDENCE
    The Cloud Control Panel's Downscale Anytime resize option was unavailable or unresponsive for about two hours; an API workaround existed.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 11:13 UTC · investigating
    Our Engineering team is investigating an issue affecting Droplet resizes using the "Downscale Anytime" option. At this time users may find this option unavailable or unresponsive in the Cloud Control Panel. As a workaround, resizes can be performed via the API while we work to resolve this issue. We apologize for the inconvenience and will share an update once we have more information.
  2. 12:43 UTC · monitoring
    Our Engineering team has identified the root cause of the issue affecting Droplet resizes using the "Downscale Anytime" option and has implemented a fix. Users should now be able to resize their Droplets using the "Downscale Anytime" option without experiencing any issues or errors. We are actively monitoring the situation to ensure the fix remains effective and will provide another update once the issue has been fully resolved.
  3. 13:28 UTC · resolved
    Our Engineering team has confirmed that the issue impacting Droplet resizes using the "Downscale Anytime" option has been fully resolved. Users can now resize their Droplets using the "Downscale Anytime" option without any issues. We appreciate your patience while we worked to resolve this issue. If you continue to experience any problems, please open a support ticket from your account so our team can investigate further.
Source
Jul 1, 202621h 13mSEV 2
Agent Timeouts While Retrieving Data from Knowledge BasesDigitalOcean agents timed out while retrieving data from Knowledge Bases, returning a retrieval timeout error. Starting July 1 at 06:25 UTC, the issue was identified and fixed, and resolved July 2 at 03:38 UTC. The provider did not state the cause or the share of agents affected.AI-graded · Agent Runtime +3
Why this grade
  1. RULES · SEV 2
    Sev 2 because Agent Runtime had degraded performance
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
    Agents timed out retrieving data from Knowledge Bases for about 27 hours; the text does not give the share of agents affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 06:25 UTC · investigating
    Our Engineering team is currently investigating an issue where Agents are experiencing timeouts while retrieving data from Knowledge Bases. As a result, affected Agents may fail to retrieve data and return the following error: "Failed to retrieve data from Knowledge base(s) - timeout" Please be assured that we are treating this as a high-priority issue and are actively working to mitigate it. We sincerely apologise for any inconvenience this may have caused and appreciate your patience and understanding. If you have any further questions, please create a support ticket so that we can investigate your specific case further.
  2. 08:39 UTC · identified
    Our Engineering team has identified the issue causing Agents to experience timeouts while retrieving data from Knowledge Bases. Please be assured that our Engineering team is actively working on a fix and is treating this issue with high priority. We sincerely apologise for any inconvenience this may have caused and appreciate your patience and understanding. If you have any further questions, please create a support ticket so that we can investigate your specific case further.
  3. 03:38 UTC · resolved
    This incident has been resolved, and our teams continue to monitor the results. If you experience any further issues, please contact support.
Source
Jun 27, 20260mSEV 2
Droplet Backup ServiceBetween 00:00 and 16:00 UTC, backups scheduled on Droplets in that window may not have been created and may appear missing. The backup service was restored and upcoming scheduled backups should run normally. The provider did not state how many customers were affected.AI-graded · Global +1
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
    Droplet backups scheduled during a 16-hour window may not have been created; the text does not say how many customers were hit.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
1 update
  1. 18:24 UTC · resolved
    Between 00:00 UTC & 16:00 UTC today, our Engineering team identified an issue affecting backup operations on Droplets. During this period, backups scheduled within this window may not have been created and may appear as missing. Our team has taken necessary measures to resolve the issue, and we can confirm that the backup service has been restored and is now functioning normally. Upcoming scheduled backups should be performed as expected. We sincerely apologize for any inconvenience this may have caused and appreciate your understanding. However, if you have any further questions or concerns, please create a support ticket for further analysis.
Source
Jun 27, 202632mSEV 2
Anthropic Inference Model AvailabilityDigitalOcean inference requests to Anthropic models failed with HTTP 400 errors, which users may have hit when calling any Anthropic model. Engineering mitigated the issue at 04:43 UTC and resolved it by 05:15 UTC on June 27, 2026. The root cause sits with Anthropic and is still being addressed by them.AI-graded · Inference +1
Why this grade
  1. RULES · SEV 2
    Sev 2 because Inference had degraded performance
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
    Requests to Anthropic models returned HTTP 400 errors for users of DigitalOcean inference; scope and duration are not fully stated.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
2 updates
  1. 04:43 UTC · monitoring
    Our Engineering team has mitigated an issue with Anthropic models. Previously, users may have encountered 400 errors when attempting to use any Anthropic model. Although the root cause of the issue is still being addressed by Anthropic, users should now be able to access and use Anthropic models again. We will continue to monitor the situation and provide updates if necessary. If you continue to experience problems, please open a ticket with our Support team. We apologize for any inconvenience this may have caused.
  2. 05:15 UTC · resolved
    Our Engineering team has resolved the issue that was causing HTTP 400 errors for requests to Anthropic models. Users should now be able to access Anthropic models without any issues. If you continue to experience problems, please open a ticket with our Support team so we can investigate further. We apologize for any inconvenience this may have caused.
Source
Jun 19, 20262h 37mSEV 4
Monitoring Graphs in the Cloud Control PanelMonitoring graphs in the DigitalOcean Cloud Control Panel were missing or unavailable for Droplets with the DO agent, Load Balancers, Databases and other services from about 13:22 to 14:26 UTC on June 19, 2026. The provider fixed the issue and confirmed restoration. Customer workloads were not reported affected.AI-graded · Global +1
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 4 · GLOBAL · HIGH CONFIDENCE
    Monitoring graphs in the control panel were missing for Droplets, Load Balancers and Databases for about an hour; apps and deploys were not reported affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 14:00 UTC · investigating
    Our Engineering team is currently investigating an issue affecting the visibility of monitoring graphs within the Cloud Panel. During this period, users may notice missing or unavailable monitoring graphs for services such as Droplets(with DO agent installed), Load Balancers, Databases, etc. We apologize for the inconvenience caused. We'll update once we have more information
  2. 14:50 UTC · monitoring
    Our engineering team has implemented the necessary fixes to address the issue affecting the visibility of monitoring graphs within the Cloud Panel. Users should now be able to view monitoring graphs for their services, including Droplets with DO Agent installed, Load Balancers, Databases, etc. We are currently monitoring the situation to ensure that the service has returned to normal operation and remain stable. We appreciate your patience and will provide an update once the issue is fully confirmed as resolved.
  3. 16:37 UTC · resolved
    Between 13:22 & 14:26 UTC today, users have experienced missing monitoring graphs for Droplets (with DO agent installed), Load Balancers, Databases, and other services within the Cloud Control Panel. Our engineering team has identified the root cause of the issue and has taken appropriate steps to restore functionality. We can confirm that services have been restored and are functioning as expected. We apologize for any inconvenience this may have caused. If you continue to experience issues viewing monitoring graphs, please create a support ticket for further analysis. Thank you for your patience and understanding
Source
Jun 16, 20262h 29mSEV 2
Intermittent 500 Errors on Serverless/GenAI Inference APIDigitalOcean's Serverless/GenAI Inference API (/v1/* endpoints) returned intermittent HTTP 500 errors and failed requests from about 22:00 to 00:30 UTC. Engineers applied mitigation steps for connectivity issues and later declared the endpoint fully operational. No root cause was given in the updates.AI-graded · Inference +1
Why this grade
  1. RULES · SEV 1
    Sev 1 because Inference had a partial outage
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
    Serverless inference API returned intermittent HTTP 500 errors and failed requests for about 90 minutes; scope across customers was not specified.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
3 updates
  1. 22:00 UTC · investigating
    We are actively investigating an issue causing elevated HTTP 500 error rates for customers utilizing our Serverless/GenAI Inference API. Customer Impact: Customers making calls to the inference API—specifically targeting /v1/* endpoints—will experience intermittent HTTP 500 errors and failed requests.
  2. 23:29 UTC · monitoring
    Our engineering teams have successfully begun implementing mitigation steps to resolve the connectivity issues affecting the inference API. We will provide another update once the API has fully recovered and error rates return to normal.
  3. 00:29 UTC · resolved
    The connectivity issues affecting our Serverless/GenAI Inference API have been fully resolved. Our engineering teams successfully completed the connectivity restoration. All systems should be functioning normally, and the endpoint should be fully operational.
Source
Jun 11, 20263h 18mSEV 2
DeepSeek V4 Pro is returning HTTP 429 "Rate limit exceeded"DigitalOcean's Gradient AI DeepSeek V4 Pro model began returning HTTP 429 'Rate limit exceeded' errors on June 11, 2026. The issue was identified and a fix implemented, and it was marked resolved about three hours after it started. The update text gives no further cause or affected share of customers.AI-graded · some customers · Model Services +1
Why this grade
  1. RULES · SEV 1
    Sev 1 because Model Services had a partial outage
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
    DeepSeek V4 Pro inference requests returned HTTP 429 rate-limit errors for about three hours; other models were not reported affected.
  3. Claude Haiku 5.5 · prompt v5 · Oct 22, 2026 · Raw record
4 updates
  1. 14:24 UTC · investigating
    We are currently facing issues with Gradient AI DeepSeek V4 Pro is returning HTTP 429 "Rate limit exceeded"
  2. 14:30 UTC · investigating
    We are continuing to investigate this issue.
  3. 14:31 UTC · identified
    The issue has been identified and a fix is being implemented.
  4. 17:42 UTC · resolved
    This incident has been resolved.
Source
Jun 4, 20261h 35mSEV 2
DNS API ServiceSev 2 because DNS had degraded performanceGlobal +4
5 updates
  1. 10:12 UTC · investigating
    Our Engineering team is investigating an issue impacting our DNS API service. During this time, users may experience issues performing domain and DNS record management operations from the Control Panel and API, including creating, updating, or deleting DNS records. As a result, services that rely on DNS API operations, such as Let's Encrypt certificate provisioning and MongoDB cluster creation, may also be impacted. We apologize for the inconvenience and will share an update once we have more information.
  2. 10:59 UTC · investigating
    Our Engineering team continues to investigate an issue impacting our DNS API service. During this time, users may experience issues performing domain and DNS record management operations from the Control Panel and API, including creating, updating, or deleting DNS records. As a result, services that depend on DNS API operations, including Let's Encrypt certificate provisioning, MongoDB cluster creation, App Platform deployments, and DigitalOcean Kubernetes (DOKS) cluster create and delete operations, may also be impacted. We apologize for the inconvenience and will share more information as it becomes available.
  3. 11:32 UTC · identified
    Our Engineering team has identified the cause of the issue impacting our DNS API service and is actively working on a fix. During this time, users may experience errors when attempting to create, update, or delete domains and DNS records through the Control Panel and API. As a result, services that depend on DNS API operations, including Let's Encrypt certificate provisioning, MongoDB cluster creation, App Platform deployments, and DigitalOcean Kubernetes (DOKS) cluster create and delete operations, may also be impacted. We will post an update as soon as additional information is available.
  4. 11:39 UTC · monitoring
    Our Engineering team has implemented a fix to resolve the issue impacting our DNS API service. Users should now be able to perform domain and DNS record management operations successfully through the Control Panel and API. Additionally, services affected by this issue, including Let's Encrypt certificate provisioning, MongoDB cluster creation, App Platform deployments, and DigitalOcean Kubernetes (DOKS) cluster create and delete operations, should now be functioning as expected. We are monitoring the situation closely and will share an update once the issue is resolved completely.
  5. 11:47 UTC · resolved
    Between 09:41 and 11:24 UTC, our Engineering team identified an issue impacting the DNS API service. During this period, users may have experienced issues performing domain and DNS record management operations through the Control Panel and API. Services dependent on DNS API operations, including Let's Encrypt certificate provisioning, MongoDB cluster creation, App Platform deployments, and DigitalOcean Kubernetes (DOKS) cluster create and delete operations, were also impacted. Our Engineering team has confirmed that the underlying issue affecting the DNS API service has been fully resolved, and all affected services are now operating normally. If you continue to experience any issues, please contact our Support team by opening a ticket. We apologize for any inconvenience caused.
Source
May 29, 20267h 44mSEV 2
App Platform DeploymentsSev 2 because App Platform - Global had degraded performanceGlobal +1
3 updates
  1. 00:14 UTC · investigating
    Our Engineering team is currently investigating an issue with build failures on App Platform in multiple regions. Users may experience errors when attempting to build their applications, resulting in failed deployments. Our Engineering team is working to fix the issue and will share an update once we have more details. We apologize for the inconvenience this issue may be causing and appreciate your patience as we work to resolve it.
  2. 01:58 UTC · monitoring
    Our Engineering team has implemented a fix to resolve the issue with build failures on App Platform. Users should see their builds deploy successfully now. We are closely monitoring the situation, and will post an update once we've confirmed this is fully resolved.
  3. 07:58 UTC · resolved
    Our Engineering team has confirmed that the issue impacting build failures on App Platform has been resolved at 07:00 am UTC. All App Platform builds are now succeeding as expected. Customers who previously encountered build failures should now be able to deploy their applications 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.
Source
May 20, 202655mSEV 2
Cloud FirewallSev 2 from the incident title (no components listed)Cloud Firewall
3 updates
  1. 12:08 UTC · identified
    Our engineering team identified an issue impacting Cloud Firewall Product. During this time, users may notice HTTP 500 errors when updating firewalls. We apologize for the inconvenience and will share an update once more information is available.
  2. 12:43 UTC · monitoring
    Our engineering team has implemented a fix that affected the Cloud Firewall rules. Users should now be able to update their firewalls successfully. We are actively monitoring the situation to ensure overall stability. We appreciate your patience and will provide an update once the issue is fully confirmed as resolved.
  3. 13:03 UTC · resolved
    Between 06:35 UTC & 12:36 UTC today, our engineering team identified an issue impacting the Cloud Firewall. During this period, users might have encountered issues while updating their firewall rules. Our team has taken appropriate measures to address the issue. We can confirm that service has been restored and is now functioning normally. We regret the inconvenience caused and appreciate your patience and understanding. However, if you continue to experience any issues, please create a support ticket for further analysis.
Source
May 20, 20262h 12mSEV 2
Cloud FirewallSev 2 from the incident title (no components listed)Cloud Firewall
3 updates
  1. 05:35 UTC · investigating
    We are currently investigating an issue with incorrect Cloud Firewall rules appearing on the cloud panel. Our engineering team is aware of the situation and actively working to identify the root cause. Since this is a user interface issue, users should not experience any problems with other services or networking. We apologize for the inconvenience and appreciate your patience. We will continue to provide updates as we learn more.
  2. 07:15 UTC · monitoring
    Our Engineering team has implemented a fix to resolve the issue causing incorrect Cloud Firewall rules to display on the cloud panel. At this time, the user interface is functioning as expected, and we are actively monitoring the situation to ensure continued stability. We will provide a final update once we have verified that the issue is fully resolved.
  3. 07:48 UTC · resolved
    Our Engineering team has verified that the issue causing incorrect Cloud Firewall rules to display on the cloud panel is fully resolved. The user interface continues to function as expected, and all systems have returned to normal operating conditions. If you continue to experience problems, please open a ticket with our support team. Thank you for your patience throughout this incident.
Source
May 20, 20264h 09mSEV 2
Block Storage Volume PerformanceSev 2 because Volumes - NYC3 had degraded performanceNYC3 +1
3 updates
  1. 01:05 UTC · investigating
    Our Engineering team is currently investigating an ongoing infrastructure issue in the NYC3 region affecting Block Storage Volumes at the storage layer. Users may experience degraded write performance and intermittent impact to services dependent on the affected storage infrastructure. We apologize for the inconvenience and will continue to provide updates as more information becomes available.
  2. 02:19 UTC · monitoring
    Our Engineering team has implemented mitigation measures for the infrastructure issue affecting Block Storage Volumes in the NYC3 region. The team is monitoring the situation, and we will share another update once the issue is fully resolved
  3. 05:13 UTC · resolved
    From 00:00 UTC to 01:40 UTC, users may have experienced degraded write performance and intermittent impacts to workloads dependent on Block Storage Volumes in the NYC3 region. Our Engineering team has confirmed that the underlying infrastructure issue affecting Block Storage Volumes at the storage layer has been fully resolved, and services are now operating normally. If you continue to experience any issues, please contact our Support team by opening a ticket. We apologize for any inconvenience caused.
Source
May 15, 202639mSEV 1
Anthropic reported outage that's impacting access to their Serverless Inference modelsSev 1 because Agent Runtime had a partial outageAgent Runtime +1
3 updates
  1. 01:21 UTC · monitoring
    As of the current time, our Engineering team is aware of an ongoing incident with our provider, Anthropic, that is impacting Serverless Inference. The outage is affecting all users attempting to use Sonnet 4.6 and Opus 4.7 models. According to Anthropic's status page (https://status.claude.com/incidents/8z7l5zcy0v3b), they are currently experiencing an outage that is causing this disruption. We apologize for the inconvenience and will provide updates as more information becomes available.
  2. 01:23 UTC · identified
    According to Anthropic's status page (https://status.claude.com/incidents/8z7l5zcy0v3b), they have identified the root cause and are actively working on a fix. At this time, users may continue to experience errors when attempting to use Sonnet 4.6 and Opus 4.7 models. We will provide another update once Anthropic has implemented a fix and service is restored.
  3. 02:00 UTC · resolved
    As of the current time, our Engineering team has confirmed that the issue with Serverless Inference has been resolved. The root cause of the issue was an outage with our provider, Anthropic, which affected users of Sonnet 4.6 and Opus 4.7 models. According to Anthropic's status page (https://status.claude.com/incidents/8z7l5zcy0v3b), they have resolved the outage. If you continue to experience problems, please open a ticket with our Support team. We apologize for any inconvenience this may have caused.
Source
May 14, 20266h 49mSEV 2
DNS service, Certificates and Managed MongoDBSev 2 because DNS had degraded performanceGlobal +2
4 updates
  1. 13:57 UTC · investigating
    Our Engineering team is investigating an issue affecting our DNS service. At this time, DNS resolution remains functional but any changes to DNS records are not being reflected at the edge. Additionally, customers may be unable to create new Let's Encrypt certificates at this time. Our engineering team is actively working to identify the root cause and restore full functionality. We apologize for any inconvenience, and we'll share more information as it becomes available.
  2. 15:52 UTC · investigating
    Our engineering team continues to investigate an issue affecting our DNS service. At this time, DNS resolution remains functional; however, new changes to DNS records are currently not being reflected at the edge. This issue is also impacting related services. Specifically, customers may be unable to create new Let's Encrypt certificates. Regarding Managed MongoDB, customers will be able to submit requests to create new clusters or scale existing ones, but the completion of the provisioning process is currently delayed. This is due to the dependency on Let's Encrypt certificate issuance, which requires functional DNS propagation. Affected clusters will automatically recover and complete their provisioning once the DNS issue is resolved. Our engineering team is actively working to restore full functionality across all affected services. We apologize for the inconvenience and will share more information as it becomes available.
  3. 16:42 UTC · monitoring
    Our Engineering team has implemented a fix for the issue affecting our DNS service and are now seeing DNS record updates successfully propagate to the edge. As a result, Let's Encrypt certificate issuance and Managed MongoDB provisioning (including scaling operations) should resume. We are currently monitoring the systems as they process the backlog of delayed requests. Affected MongoDB clusters and certificate requests should complete their provisioning automatically. We will continue to monitor the situation closely to ensure full stability. We appreciate your patience throughout this process and will provide an update once the issue is fully confirmed as resolved.
  4. 20:46 UTC · resolved
    As of 19:50 UTC, the issue affecting the DNS service has been fully resolved, and all related services, including Let's Encrypt certificate issuance and Managed MongoDB provisioning, are now operating normally. The backlog of delayed requests has been successfully processed, and all DNS record updates, pending certificate, and MongoDB operations should now be complete. We apologize for the disruption this caused and appreciate your patience while our team worked to restore full functionality. However, if you continue to experience any issues, please don't hesitate to raise a support ticket for further investigation. We'll be happy to assist you.
Source
May 12, 202647mSEV 1
GradientAI: Agent Platform Playground Interaction ErrorsSev 1 because Agent Runtime had a partial outageAgent Runtime +1
5 updates
  1. 10:24 UTC · investigating
    We are currently investigating an issue affecting the GradientAI Agent Platform Playground. Users may see a “Something went wrong” error for all agent interactions in the Playground. Agent functionality through API endpoints remains unaffected. We are actively working to identify the cause and will provide an update as soon as more information is available.
  2. 10:50 UTC · identified
    We have identified the cause of the issue affecting the GradientAI Agent Platform Playground. Our engineering team is implementing a fix, and we will provide another update as soon as it is available.
  3. 11:14 UTC · identified
    A fix has been applied for the issue affecting the GradientAI Agent Platform Playground, and we are observing recovery in service behavior.
  4. 11:36 UTC · monitoring
    We have applied a fix for the issue affecting the GradientAI Agent Platform Playground and are monitoring the service to ensure continued stability. At this time, we are no longer observing new reports related to this issue.
  5. 11:37 UTC · resolved
    The remediation for the issue affecting the GradientAI Agent Platform Playground has been fully implemented, and the service is operating normally. We are no longer observing customer impact related to this issue, and the incident has been resolved.
Source
May 9, 20263h 27mSEV 3
Control Panel Errors - Unable to Enable 2FA and Google/GitHubSev 3 from the incident title (no components listed)Cloud Control Panel
3 updates
  1. 11:15 UTC · investigating
    Our Engineering team is investigating an issue affecting the ability to enable Two-Factor Authentication (2FA) and Google/GitHub authentication through the Control Panel. During this time, users may encounter errors while enabling these authentication methods and could also experience issues accessing teams with secure sign-in enabled. We apologize for the inconvenience and will provide an update as soon as more information becomes available.
  2. 13:51 UTC · monitoring
    Our Engineering team has implemented necessary changes to address the issue affecting the ability to enable Two-Factor Authentication (2FA) and Google/GitHub authentication through the Control Panel. Our team is currently monitoring the situation to ensure stability. We appreciate your patience and will provide an update once the issue is fully confirmed as resolved.
  3. 14:42 UTC · resolved
    Between 5:35 and 14:25 UTC today, our Engineering team identified an issue that prevents enabling Two-Factor Authentication (2FA) and Google/GitHub authentication through the Control Panel. During this period, users might have encountered issues while enabling authentication methods and accessing teams with secure sign-in enabled. Our team has taken appropriate measures to address the issue. We can confirm that service has been restored and is now functioning normally. We regret the inconvenience caused. However, if you continue to experience any issues, please create a support ticket for further analysis.
Source
May 8, 20261h 08mSEV 2
Let's Encrypt Outage Affecting Certificate Issuance and Managed Databases OperationsSev 2 because App Platform - Global had degraded performanceGlobal +5
2 updates
  1. 20:46 UTC · identified
    Our Engineering team is aware of an upstream outage with Let's Encrypt (see https://letsencrypt.status.io/) which impacts the following services: - Inability to create new Let's Encrypt certificates for Spaces, Load Balancers, and App Platform Custom Domains - Stuck or delayed creates/forks/restores on Mongo, PG, and MySQL databases. Please note that operations related to Managed Databases and App Platform Custom Domains will automatically retry and should complete successfully once the upstream outage is resolved. We'll continue to monitor this situation and provide updates. We apologize for the inconvenience.
  2. 21:54 UTC · resolved
    The upstream outage with Let's Encrypt has been resolved. Customers should now be able to issue Let's Encrypt certificates for Spaces, Load Balancers, and App Platform Custom Domains. Our Engineering team has also confirmed that stuck or delayed actions with Mongo, Advanced PG, and Advanced MySQL databases should complete normally now. We appreciate your patience. If you continue to experience any issues, please open a support ticket from within your account.
Source
May 8, 20261h 58mSEV 2
Multiple Services in NYC2Sev 2 because App Platform - New York had degraded performanceAPI +7
4 updates
  1. 18:01 UTC · investigating
    We are currently investigating an issue affecting multiple services in our NYC2 region. Our engineering team is aware of the situation and is working to identify the root cause and restore full connectivity as quickly as possible. Users with resources in the NYC2 region may experience issues with Droplet connectivity, API requests, or other services. We will provide additional updates as more information becomes available. We apologize for any inconvenience this may cause.
  2. 19:21 UTC · monitoring
    Our Engineering team has identified the issue and implemented a fix to resolve the issues with multiple services, and is monitoring the situation. We will post an update as soon as the issue is fully resolved.
  3. 19:53 UTC · monitoring
    We are continuing to monitor for any further issues.
  4. 19:59 UTC · resolved
    Our engineering team has resolved the issue with multiple services in NYC2 region, and all services should now be operating normally. If you continue to experience problems, please open a ticket with our support team. We apologize for any inconvenience and thank you for your patience.
Source
Apr 28, 20265h 48mSEV 2
Elevated 5xx “context canceled” errors impacting serverless inferenceSev 2 because Agent Runtime had degraded performanceAgent Runtime +1
4 updates
  1. 13:45 UTC · investigating
    Serverless inference customers are experiencing elevated 5xx errors, including “context canceled” responses. This may result in intermittent request failures. Our team is actively investigating and will provide updates as more information becomes available.
  2. 15:59 UTC · identified
    We have identified an issue affecting our service and are currently working to implement a fix. Our team is actively investigating and taking the necessary steps to restore normal operations as quickly as possible. We appreciate your patience and will provide updates as soon as more information becomes available.
  3. 19:00 UTC · monitoring
    Service for Serverless Inference has been restored. We’ve implemented tighter rate limits to help prevent recurrence and are closely monitoring system performance. Some users may still experience intermittent latency as we complete final stabilization efforts. Our team remains actively engaged to ensure full recovery. We appreciate your patience and will provide further updates as needed.
  4. 19:33 UTC · resolved
    All services are operating normally. We will continue to monitor the system to ensure ongoing reliability. Thank you for your patience while we worked to resolve this issue.
Source
Apr 27, 202659mSEV 1
Serverless Inference - Intermittent Rate Limiting Affecting Some Customers Using Anthropic ModelsSev 1 because Agent Runtime had a partial outageAgent Runtime +1
3 updates
  1. 10:38 UTC · investigating
    We are investigating an issue affecting some customers using DigitalOcean Serverless Inference with Anthropic models. Over the last two hours, impacted customers may have experienced intermittent request failures, including HTTP 429 responses, on some Anthropic model requests. Our engineering team is actively investigating the issue. We apologize for the inconvenience and will share another update as soon as more information is available.
  2. 11:07 UTC · monitoring
    We identified the cause of intermittent HTTP 429 responses affecting some customers using Anthropic models on DigitalOcean Serverless Inference and applied a mitigation. Service has recovered, and we are monitoring stability.
  3. 11:37 UTC · resolved
    The issue is resolved, and service is operating normally.
Source

Peers, 90 days

Compare
HerokuGrade A+100.00% up0 incidentsMTTR –$7/moNetlifyGrade B100.00% up17 incidentsMTTR 34m~$20/moRenderGrade C100.00% up13 incidentsMTTR 1h 35m$21.25/moVercelGrade C100.00% up23 incidentsMTTR 47m~$20/moDigitalOceanGrade F100.00% up18 incidentsMTTR 4h 02m$6/moFly.ioGrade F99.38% up26 incidentsMTTR 44m$5.69/moCloudflareGrade F100.00% up54 incidentsMTTR 1h 13m~$5/moRailwayGrade F98.31% up27 incidentsMTTR 55m~$12/mo

README badge

DigitalOcean's live grade, for your README.

DigitalOcean grade badge
[![digitalocean on downagain.dev](https://downagain.dev/badge/digitalocean.svg)](https://downagain.dev/p/digitalocean)