IL-0155 DigitalOcean · 2026-07-09kubernetesnetworking

Some DOKS clusters in NYC1 saw intermittent DNS timeouts and NodeNotReady events because CoreDNS ran on shared-CPU Droplet worker nodes

A small number of DigitalOcean Kubernetes (DOKS) clusters in NYC1 had intermittent DNS timeouts. Their worker nodes ran on shared-CPU Droplets, and DigitalOcean documents shared-CPU nodes as a limitation for latency-sensitive cluster DNS workloads such as CoreDNS.

The status page reported the problem as subsided at 01:18 UTC on July 10 and resolved at 01:27 UTC on July 11, with the affected clusters working. DigitalOcean recommended running CoreDNS on node pools with dedicated, not shared, CPUs and with enough CoreDNS replicas, and asked customers who still saw DNS failures or NodeNotReady events to open a support ticket.

Severity: –
Scope: a small number of DOKS clusters in NYC1 whose worker nodes ran on shared-CPU Droplets
Users affected: –
Region: NYC1
Time to detect: –
Time to resolve: 4h 47m

Symptoms

From 20:31 UTC on July 9, 2026, DigitalOcean reported a problem with Kubernetes deployments in its NYC1 region. Application workloads could see intermittent DNS failures and NodeNotReady events.

Symptom ? DNS resolution failures Intermittent timeouts Node NotReady

Root cause

Root cause ? Capacity exhaustion

Component ?CoreDNS Node pool

Contributing factor ?Unknown limit

Trigger: –

Detection

–

Remediation

–

Action items

–

Lessons

Cluster DNS is sensitive to latency, and CoreDNS on shared-CPU nodes can time out intermittently. DigitalOcean's advice is to place CoreDNS on dedicated-CPU node pools and to run enough CoreDNS replicas.

Sources

https://status.digitalocean.com/incidents/2kxtxyvzzzk0 · official-status

Related cases

IL-0102 CoreDNS pods on a production EKS cluster ran out of memory under a burst of new pods, endpoints and nodes, taking down the Buildkite web UI, APIs and job dispatchBuildkite · 2026
same root cause · shared CoreDNS, Node pool
IL-0082 Losing one CoreDNS pod during a planned EKS node reroll overloaded the remaining CoreDNS pods, causing DNS timeouts and errors across multiple services at RebelMouseRebelMouse · 2025
same root cause · shared CoreDNS, Node pool
IL-0027 All CoreDNS pods landed on one node, the node ran out of memory, and DNS for the whole service went downBackpackr · 2025
same root cause · shared CoreDNS, Node pool
IL-0100 PostHog's feature flags pods were packed onto Kubernetes nodes that were too small for their CPU requests, and CPU saturation above 90% caused three outages in ten days through Redis overload, connection pool exhaustion and slow queriesPostHog · 2025
same root cause · shared Node pool
IL-0048 DNS lookups timed out in a large EKS cluster when CoreDNS hit the 1024 packets-per-second link-local limit, driven by sudo hostname lookupsunknown · 2025
same root cause · shared CoreDNS
IL-0099 User servers on 2i2c's Earthscope hub took over 15 minutes to start and kernels were killed during a workshop, because a profile option guaranteed 8 GB of memory with no limit on 32 GB nodes2i2c · 2025
same root cause · shared Node pool
IL-0204 An etcd memory spike overloaded the control plane of a Render Frankfurt cluster, and DNS then failed because CoreDNS ran on the rebooted control plane nodes and could not start without the API serverRender · 2024
same root cause · shared CoreDNS
IL-0182 Too few CoreDNS replicas on EKS were overloaded during traffic spikes, raising latency and cutting the network for task pods, and the over-provisioned, tightly spread CoreDNS pods added later blocked Karpenter consolidation