Is Hetzner reliable enough for production?
Hetzner is reliable enough for production if you design for the failure of a single server or a whole location, because the platform guarantees less than a hyperscaler does. Its cloud SLA promises 99.9% monthly availability per server, pays out only in cloud credit, and Hetzner has no availability zones inside a location. Teams that spread workloads across locations, keep backups outside Hetzner and manage infrastructure as code run production on it; teams that expect the provider to absorb failures for them do not.
What the SLA covers
Hetzner’s cloud SLA commits to “commercially reasonable efforts” for 99.9% availability of each cloud server per calendar month. That allows about 43 minutes of downtime in a 30-day month. Key terms from the full SLA text:
- Compensation is non-refundable cloud credit, calculated from the server’s hourly rate for the downtime beyond the threshold. Hetzner’s own example credits €0.87 for 185 minutes of downtime on a server costing €0.3671 an hour.
- You must claim the credit within 14 days after the end of the month.
- Scheduled maintenance, announced at least 24 hours in advance, does not count as downtime. Neither do denial-of-service attacks.
- Firewalls, load balancers, snapshots and backups are excluded from the SLA.
An SLA is a refund policy, not a reliability measurement. The article on Kubernetes SLAs explains how to read these terms for any provider.
Infrastructure failure domains
Hetzner Cloud has six locations in four network zones. The EU network zone, eu-central, contains Falkenstein (fsn1), Nuremberg (nbg1) and Helsinki (hel1). There are no availability zones inside a location, so the location is the smallest failure domain you can choose.
| Scope | Tool | What it protects against |
|---|---|---|
| Host | Spread placement group, up to 10 servers on different physical hosts | One physical server failing |
| Location | Servers in two or three EU locations, joined by a private network | A location outage or maintenance window |
| Provider | A second provider or your own hardware | Account suspension, a capacity freeze, a provider-wide incident |
Some resources are tied to a location and some to a network zone. A volume attaches only to servers in its own location, according to the API reference. Volumes store every block on three physical servers. Private networks and Floating IPs span a whole network zone, so a Floating IP can move between servers in Nuremberg and Helsinki.
Capacity and account risks
Two risks have nothing to do with hardware failing.
Capacity. Since 26 June 2026, Hetzner’s status page has carried an incident titled “Limited availability of cloud instances”. Hetzner says high demand and limited hardware supply restrict new server creation for new customers and for some randomly selected existing customers. Its cloud FAQ adds that when a location is restricted, affected customers can neither create nor rescale servers there, while existing servers keep running. For production, this means a scale-out or a replacement after a failure can fail. Keep spare capacity, allow more than one server type and location in your automation, and read why you can’t create a Hetzner server for the error codes.
Account. Hetzner runs fraud checks on registrations and first orders and may ask for ID or a prepayment. Like other providers, Hetzner can restrict or suspend an account over unpaid invoices or an abuse review, and that affects every project in it. Pay by a method that does not expire unnoticed, keep contact details current, and treat the account itself as a single point of failure.
A production design pattern
Teams that run production on Hetzner usually combine these practices:
- Run at least three nodes per tier in a spread placement group so that one host failure takes out one replica.
- Place replicas of stateful services, such as a PostgreSQL primary and its standbys, in at least two EU locations, connected over a private network. Expect more latency between Germany and Finland than between servers in one location.
- Put Hetzner Load Balancers or a Floating IP in front of each entry point, with health checks.
- Store backups and database WAL archives outside Hetzner, for example in object storage at another provider, so that an account or location problem cannot take backups down with production.
- Define servers, networks and firewalls in Terraform or a similar tool, so you can rebuild in another location or at another provider from code.
- Watch status.hetzner.com for planned maintenance, which is excluded from the SLA.
Kubernetes helps with steps 1 to 3, because it reschedules Pods from failed nodes and spreads replicas with topology constraints. The guide to highly available multi-cluster Kubernetes covers the step to a second provider.
Security and compliance
Hetzner holds ISO/IEC 27001:2022 certification and a BSI C5 Type 2 attestation. The C5 audit covered cloud servers, volumes, load balancers, vSwitches and Floating IPs at its European sites in Gunzenhausen, Nuremberg, Falkenstein and Helsinki, over the period from 1 February to 31 August 2025. Hetzner is also classified as a KRITIS operator in Germany.
Running Kubernetes on Hetzner
The Hetzner Kubernetes guide compares self-managed and managed options. Cloudfleet’s managed Kubernetes for Hetzner runs the control plane outside your Hetzner account with a 99.95% uptime SLA on the Pro plan, and node auto-provisioning replaces failed Hetzner servers automatically.