Hetzner status

How we check Hetzner

We watch api.hetzner.cloud 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 pin the exact response code the Hetzner Cloud API returns to an unauthenticated request rather than assuming any 2xx, since a bare request with no token is correctly rejected on a healthy day and treating that rejection as downtime would misreport every one of those healthy days.

We also watch console.hetzner.cloud as a separate monitor, on the same schedule and with the same confirmation rule. It has its own board above, because the two fail independently and one board reporting healthy says nothing about the other.

The console is the management interface, and it is the one that matters when you need to reboot a server or change a firewall rule during an incident. It fails separately from the API, so it gets its own board rather than being averaged into one reassuring dot with it.

What is Hetzner?

Hetzner is a European cloud and dedicated-server provider best known for offering solid hardware at prices well below the larger American cloud platforms, which has made it a popular choice for cost-conscious startups, side projects, and self-hosted infrastructure of every kind. A team running its own database, a small SaaS product, or an internal tool often ends up on Hetzner specifically because it lets them run real servers without the hourly-billed markup a hyperscaler charges for the same underlying capacity.

That cost advantage comes with a tradeoff worth naming plainly: a team on Hetzner is typically doing more of its own infrastructure work than a team on a fully managed platform would, provisioning, patching, and watching their own servers rather than leaning on a platform to abstract all of that away. Which means when something goes wrong, the first question is almost always whether the problem is Hetzner's infrastructure or the team's own server configuration, and that distinction is not always obvious from the outside. A server that stops responding looks identical whether the underlying network is down or a process on the server itself has crashed.

Hetzner's own incidents are typically scoped to a specific data center or network segment rather than the entire platform at once, since its infrastructure spans multiple physical locations that do not all share a single point of failure. That is exactly the kind of partial incident a single-location check cannot distinguish from a dead server, and a multi-region one can, if the API answers cleanly from every region we probe, the underlying network is very likely fine and the problem is local to your own server.

If your own Hetzner-hosted service is unreachable and the board above shows Hetzner itself healthy, the more likely explanations are a crashed process, a firewall rule you changed, or a resource limit, disk, memory, or connection count, hit on your own server, rather than the underlying platform.

The console deserves separating from the API, which is why this page watches both. When the management interface is unreachable, running infrastructure carries on: servers keep serving and traffic is unaffected, because none of that depends on a browser session. What is lost is the ability to change anything. That is an operational problem rather than a customer-facing one, and the distinction is worth making out loud during an incident, because the instinctive reading of "I cannot reach Hetzner" is that production is down when production is usually fine.

The exception is the case where the two collide. If a server has a problem at the same moment the console is unavailable, the tools for fixing it are the ones that are missing. Rebooting, opening a recovery console, or adjusting a firewall rule all run through the management interface, so a control plane outage turns an ordinary five-minute fix into a wait. Having a second path matters here, and there is one: the cloud API is a separate surface from the web interface and is sometimes reachable when the browser is not.

Frequently asked questions

Is Hetzner down right now?

Check the boards above; there are two, one for the Hetzner Cloud API and one for the cloud console, each refreshed every couple of minutes from all five of our regions.

If the cloud console is down, are my servers down too?

Almost certainly not. The console is the control plane, and your servers, volumes, and load balancers keep running without it. What you lose is the ability to create, reboot, resize, or reconfigure anything, which matters during an incident and is invisible to your users.

What can I still do while the console is unavailable?

More than you might expect. SSH into a running server works if the server and network are healthy, since it does not touch the console at all, and the cloud API is a separate path that is sometimes reachable when the web interface is not. A CLI or a small script can be the difference between acting and waiting.

My server hosted on Hetzner is not responding. Is that a Hetzner outage?

Not necessarily. A crashed process, a misconfigured firewall rule, or a full disk on your own server produces the exact same symptom, unreachable, as a real Hetzner-side incident. If the board above shows Hetzner healthy, check your own server's console and logs before assuming an outage.

Does a Hetzner incident affect every server everywhere?

Rarely. Incidents are more commonly scoped to a specific data center or a specific network segment than to every server across every location failing at once, which is why a monitor checking from more than one region is worth more than one checking from a single vantage point.

What is the difference between this page and Hetzner's own status page?

Theirs reflects incidents Hetzner's own team has confirmed and posted. Ours reflects what we measure independently, from outside their infrastructure, on a fixed schedule regardless of whether an official update has gone up yet.