# Hetzner status

> Is Hetzner down? Live status for the Hetzner Cloud API and the cloud console, watched as separate monitors, with uptime and per-region timings.

Published: 2026-08-24 | Canonical: https://yoping.me/status/hetzner

## 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. The two fail independently, and one 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.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/hetzner. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## 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.