DigitalOcean status

How we check DigitalOcean

We watch api.digitalocean.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the API host that the control panel, the CLI, and every automation you have written all depend on, and we pin the response an unauthenticated request receives. Your own droplets answer on their own addresses and their health is your responsibility rather than DigitalOcean's, so probing one would measure your server, not their platform.

What is DigitalOcean?

DigitalOcean sells cloud infrastructure aimed at developers and smaller teams: virtual machines, managed databases, object storage, Kubernetes, and an application platform, with pricing that is easier to predict than the larger providers. For a lot of small companies and side projects it is the whole of production, which makes an incident there considerably more consequential than the size of the bill would suggest.

The most useful distinction during any incident is between the control plane and the resources it manages. The control panel, the API, and the CLI are how you create and change things. Your droplets, databases, and load balancers run independently of them. When the control plane is degraded you cannot resize a droplet, add a firewall rule, or restore a backup, and your users notice nothing at all, because the servers keep serving. Conversely, a compute or network problem in a datacentre takes your users down while the control panel stays perfectly usable. Treating these as one condition leads people to escalate during a control plane blip and to stay calm during something that genuinely matters.

Regional scope is the second thing to check. DigitalOcean operates datacentres in several parts of the world and incidents are normally confined to one, so a published incident may be entirely irrelevant to your account. This is also why reports conflict during an event: someone running in one region sees a total outage while someone in another sees nothing. Knowing which region each of your resources actually sits in is a small piece of homework that pays for itself the first time it comes up.

Most droplet outages are not DigitalOcean's fault, and it is worth being honest about that before checking any status page. A disk that filled with logs, a process killed for exhausting memory, an unattended upgrade that restarted something at four in the morning, or a firewall rule tightened during unrelated work are all far more common than a hypervisor problem. The recovery console in the control panel is the tool for these, because it gives you a session even when SSH is the thing that broke.

Managed databases add one predictable failure of their own. Every plan has a connection limit, and application architectures that open connections per worker or per invocation exhaust them under load while the database itself remains healthy. The errors look like unavailability and are actually a bounded resource doing what it was configured to do.

Frequently asked questions

Is DigitalOcean down right now?

Check the board above; it reflects our own probes against DigitalOcean's API from all five of our regions, refreshed every couple of minutes. This measures the platform's control plane, not whether your individual droplet is running.

My droplet is unreachable but this page shows DigitalOcean up. What now?

Check the droplet itself, because a single server going down is usually about that server. A full disk, an out-of-memory kill that took the web server with it, a firewall rule changed during unrelated work, or a kernel update that did not come back cleanly will all make a droplet unreachable while DigitalOcean's platform is entirely healthy. The console access in the control panel gets you a session that does not depend on SSH working.

Does a DigitalOcean incident affect every region at once?

Rarely. Incidents are usually scoped to one datacentre region, which is why the region your resources are in is the first thing to check against any published incident. Two people running on DigitalOcean can have completely different experiences during the same event, and both are reporting accurately.

Is the control panel being down the same as my servers being down?

No, and the difference is worth keeping straight during an incident. The control panel and API are the control plane; your droplets, databases, and load balancers keep running when it is unavailable. What you lose is the ability to create, resize, reboot, or reconfigure anything, which is disruptive for operations and invisible to your users.

Why is my managed database refusing connections after a traffic spike?

Because managed database plans have a connection limit, and applications that open a connection per worker or per function invocation reach it faster than expected. The database is healthy and declining new connections, which produces errors that read like an outage. Connection pooling is the fix, and it is much easier to set up before the spike than during one.