DigitalOcean's VPC Networking layer broke for 1h 39m on 5 October 2026, stopping customers from creating or deleting VPC peerings, routes, subnets and Private Network Connections. The fault sat inside DigitalOcean's own networking control plane, not in your product.
Started
10:38 UTC
Duration
Lasted 1h 39m
Source
IsDown
Next time
DigitalOcean is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Global
What happened?
DigitalOcean's status page says the disruption actually began at 08:48 UTC, though the first public update was not posted until 10:38 UTC when engineers identified it. The affected operations were specific: creating or deleting VPC peerings, VPC Native DOKS clusters, Private Network Connections, cluster member additions, and creating routes and subnets. DigitalOcean was explicit that existing VPC resources and network connectivity kept working throughout, so this was a control plane problem rather than a data plane one. Only one component is listed as affected, "Global", meaning this was not scoped to a single region. At 11:02 UTC DigitalOcean reported a fix was in place and that pending operations had been cleared. At 12:13 UTC the incident was marked resolved, with DigitalOcean stating full recovery had actually landed at 10:29 UTC, before the 11:02 update was even posted. That gap between the stated recovery time and the published update time is worth noting if you're trying to reconcile your own logs against DigitalOcean's timeline. No user reports were filed during this window on the record available. DigitalOcean has not published a post-mortem explaining why the disruption started at 08:48 UTC, only what it affected and when it ended. There were three updates in total across the incident's life, and all three came from DigitalOcean directly.
Learning
This incident shows why checking an API endpoint and checking a control-plane operation are two different tests. UptimeRobot's own probes against DigitalOcean's API component across EU and NA regions stayed at 100% uptime through this entire window, and that reading is accurate: the API itself answered requests normally. What broke was the ability to create, delete or modify specific VPC networking objects, a narrower and deeper function than basic API reachability. Existing connectivity was unaffected, which is exactly why a simple reachability check would never have caught this. If your product depends on provisioning VPC peerings or routes on demand, you'd have seen failures or delays there even while every outward-facing check stayed green. This is a known shape of cloud outage: the control plane that manages infrastructure breaks while the infrastructure already running keeps serving traffic. Your own monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
