DigitalOcean's Managed Kubernetes service lost external DNS resolution for 1h 27m on 11 October 2026. The fault sat inside DigitalOcean's DNS infrastructure, not in anything you run on your clusters.
Started
22:01 UTC
Duration
Lasted 1h 27m
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 logged one incident on this day, starting at 22:01 UTC and lasting 1h 27m. The title was "DNS Resolution for Managed Kubernetes" and the single affected component was marked Global, meaning the problem was not confined to one region. DigitalOcean's first update said its engineering team was investigating intermittent external DNS lookup failures for Managed Kubernetes clusters in multiple regions, and warned that applications on those clusters might intermittently fail to resolve external domain names. That is a specific and disruptive failure mode: a pod can be running fine and still be unable to reach an external API or database host because the name never resolves. At 22:54 UTC, 53 minutes later, DigitalOcean posted that a fix had been implemented and that it was monitoring the results. No further update followed, and DigitalOcean never posted a resolved notice in this record, so the incident closes out at 1h 27m based on that last entry. There is only one filing on each side of the fix, which means DigitalOcean's own confidence that the problem is fully gone rests on a single monitoring statement rather than a confirmed resolution. No user reports were filed during this window. DigitalOcean's 90 day history shows 21 incidents with a median duration of 3 hours 46 minutes, so this one ran shorter than DigitalOcean's typical recent incident.
Learning
UptimeRobot's own probes watched DigitalOcean's API component from both EU and NA regions through this window and recorded 100% uptime across 24 hours, 7 days and 30 days, with nothing registered against this specific incident. That is not a contradiction. The fault lived in internal DNS resolution for workloads running inside Managed Kubernetes clusters, a layer that sits between DigitalOcean's control plane and your application's outbound traffic, not in the API endpoint that external monitoring queries. A probe hitting DigitalOcean's API will come back green even while pods on your cluster are failing to resolve names for services they depend on, because the two are checking entirely different paths through DigitalOcean's infrastructure. This is the shape to recognise: your own health checks can look clean while your actual workloads are silently failing outbound calls, because the breakage is happening one layer below what you are watching. Over 30 days UptimeRobot recorded 4 incidents on DigitalOcean with a median resolution time of 1h 33m, which is close to what this one actually took. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
