DigitalOcean outage history

DigitalOcean experienced a brief network connectivity issue affecting users in India trying to reach resources in the NYC region. Affected users reported increased latency, packet loss, and intermittent connections on the NYC1 networking path, with carriers including Airtel and BSNL noted in the incident details. The event began at 10:40 AM UTC and was resolved by 11:50 AM UTC, lasting a little over an hour. DigitalOcean categorized the issue as Network connectivity problems for the NYC1 path and provided updates as engineers investigated and worked toward restoration. The impact appeared regional rather than global, with no evidence of a wider service disruption.

Users attempting to access the llama-4-maverick model via DigitalOcean's Serverless Inference encountered HTTP 500 errors, effectively rendering the llama-4-maverick model unavailable. The issue was centered on the Agentic Inference Cloud / Inference component. The incident began at 11:21 AM UTC and was resolved by 12:40 PM UTC as service returned to normal, with DigitalOcean's Engineering team actively investigating and communicating updates with high priority.

DigitalOcean's status updates indicated that a scene of degraded availability for the llama-4-maverick model triggered the incident, and the team worked to restore normal operation during the window above. The service returned to full health after remediation, resuming normal access to the model via Serverless Inference.

Users attempting to run Gradient AI Serverless Inference requests for the qwen3.5-397b-a17b model experienced timeouts as DigitalOcean's Agentic Inference Cloud / Inference encountered an outage. The issue began at 4:55 PM UTC as the service moved from healthy to degraded, prompting an ongoing investigation. By 7:45 PM UTC, the status had returned to up, indicating the component had recovered. The disruption lasted roughly 2 hours and 50 minutes, and the impact was focused on serverless inference for the specified model within the Agentic Inference Cloud / Inference, with no wider service impact apparent. DigitalOcean communicated the investigation and subsequent recovery via their status updates, and the affected component stabilized.

Users faced difficulties attaching DigitalOcean block storage volumes to droplets starting in the NYC1 and NYC3 regions, affecting workloads that rely on persistent storage. The DigitalOcean Engineering team began investigating as the issue was flagged in the NYC1/NYC3 region at 9:55 AM UTC, with volumes in those regions listed as impacted. The problem then expanded to BLR1, SGP1, and SYD1 by 1:40 PM UTC, as the scope of affected volumes grew and the status stayed at degraded for a period of time. The incident was resolved when all affected volumes returned to normal by 2:55 PM UTC, marking the end of the disruption after several hours of impact.

The BLR1 region experienced outbound network connectivity problems for DigitalOcean Droplets, causing timeout errors when reaching external services. The incident began around 7:00 AM UTC as engineers investigated the BLR1 networking path, with users reporting connectivity issues and degraded performance from multiple regions including India, Nigeria, and the United States.

An update at 8:30 AM UTC noted that the issue involved upstream connectivity and that DigitalOcean was coordinating with upstream providers to implement a resolution. Intermittent timeouts persisted for Droplets in BLR1 as the team worked to restore normal outbound connectivity. The BLR1 networking problem was resolved by 9:40 AM UTC and the affected component returned to an operational state.

DigitalOcean reported a degraded condition in the TOR1 region affecting Reserved IP routing, causing inbound and outbound traffic to and from Reserved IPs in TOR1 to fail. The outage impacted services relying on Reserved IPs for external reachability and inter-droplet communication. The incident began around 1:40 PM UTC, and DigitalOcean suggested a workaround: detaching and reassigning the Reserved IP to the Droplet may restore connectivity.

An update at 3:36 PM UTC confirmed the cause had been identified and a fix was being implemented, with further updates planned as the team works toward restoration.

Impact began on Jul 13, 2026 7:05 PM UTC when DigitalOcean flagged latency issues affecting the Gemma4 model on the Serverless Inference and Dedicated Inference platforms. The root cause was a backend configuration issue in the Gemma4 inference path, which led to severe latency and occasional request timeouts for workloads relying on Gemma4. A fix was deployed by 10:25 PM UTC as engineers began monitoring performance to validate recovery.

DigitalOcean reported a degraded condition affecting Kubernetes deployments in NYC1, with intermittent DNS failures and NodeNotReady events impacting workloads in the region. Impact began at 8:35 PM UTC and persisted until 1:20 AM UTC when the NYC1 Kubernetes component returned to normal operation. Engineers investigated and applied mitigations as the status page described the issue under the Kubernetes / NYC1 component, with the service returning to a healthy state once the issues were resolved.

Users attempting to use the Deepseek V4 Pro model in DigitalOcean's Serverless Inference and Agent Platform encountered errors, typically 429 responses, starting at 10:15 PM UTC. The impact was focused on the Deepseek V4 Pro path, with two components in the Agentic Inference Cloud entering a degraded state: Inference and Model Services. DigitalOcean's Engineering team was actively investigating and promised updates as more information became available.

Users managing DigitalOcean Managed Database Clusters faced delays for several hours starting at Jul 2, 2026 10:05 PM UTC. The issue affected operations to create, scale, fork, and restore Standard MySQL, Standard PostgreSQL, OpenSearch, Kafka, and Valkey clusters accessible through the Cloud Control Panel or API. DigitalOcean’s engineering team indicated an ongoing investigation affecting the Global Event Processing and Global Managed Databases components, with visibility gradually returning as the platform started to recover and was back to normal by Jul 3, 2026 6:25 AM UTC.