Why Hetzner charges for stopped servers

The first time it happens, it seems to be a billing bug. You shut down a Hetzner cloud server before going on holiday and, when you come back two weeks later, the invoice shows the full monthly rate as if the machine had been running the whole time. It wasn't. Hetzner billed you for it anyway.

The instinct, especially for anyone familiar with AWS, GCP or Azure, is to assume that the system misclassified the state. It didn't. Hetzner deliberately bills powered-off servers at the full rate, and this is a structural issue, not a UX oversight or a missed feature. It is more useful to understand why this is the case than to complain about it, because this policy is directly related to how Hetzner keeps prices low in the first place.

What Hetzner actually says

Hetzner's billing FAQ is clear on this point:

Until you, the customer, delete your servers, we will bill you for them, regardless of their state.

The FAQ goes on to explain that Hetzner allocates full resources to a server, regardless of its power state. This allows for a fast startup when the server is booted again. Two things follow. Firstly, the only way to stop billing is to delete the server — not to stop, shut down or detach it. Secondly, the CPU cores, RAM and disk storage allocated to the server are physically reserved on a specific host in a specific data centre until they are released.

This is the opposite of the AWS model. On EC2, stopping an instance drops the compute charge to zero and you only pay for the EBS volume backing it (see AWS EC2 lifecycle docs). The instance type, security groups and metadata are preserved, but the physical capacity is released back into the regional pool. When you start the instance again, AWS schedules it onto whichever host has room. The same applies to GCP and Azure.

Hetzner does not do that. The capacity remains allocated to your server until you delete it.

Why Hetzner bills stopped servers

The choice between "release capacity on stop" and "hold capacity until delete" is not arbitrary — it determines how a cloud provider must size its fleet.

If powered-off servers were free, Hetzner would face two unappealing options. The first option would be to keep the underlying capacity reserved in the same data centre and on a host that can boot the same type of VM. This capacity could not be sold to another customer. Hetzner would be paying for hardware, power, cooling, and rack space that generates no revenue. This cost would have to be factored into the price of every other server in the fleet. The second option would be to release the capacity and oversubscribe. The next time the customer clicks 'Start', Hetzner would need to find space for the VM immediately. Sometimes there would be no space and the start would fail with a capacity error. The customer would, quite reasonably, be furious. That would be damaging to Hetzner's reputation as a low-cost but reliable cloud provider.

With free stopped servers, the same hardware would carry fewer paying slots.

Both of these outcomes are worse than the current policy for almost every kind of customer. The current policy makes the trade-off explicit: if you want reserved capacity, pay for it; if you don't need it, delete the server and free up the slot. This empowers the operator, who is in the best position to decide whether the server is needed, and enables Hetzner to run at full capacity with minimal idle inventory. This is one of the reasons why a CCX13 in Falkenstein costs a fraction of what a comparable dedicated vCPU shape costs on AWS or Azure.

Hetzner's own product line proves the point

If you doubt that Hetzner runs at full capacity, take a look at the Cost-Optimized line. The CX series (CX23, CX33, CX43 and CX53), which was launched at the end of 2025 to replace the older CX11 generation, is Hetzner's cheapest tier. It consists of entry-level shared vCPUs aimed at test environments, blogs and low-traffic projects. The product page itself describes the trade-off in plain language: "this resource-saving use means that the number of available servers is limited" (hetzner.com/cloud/cost-optimized).

In practice, the Hetzner Console occasionally displays "Limited availability" against Cost-Optimized server types and creation may fail when the allocation pool in a given location is depleted. CX and CAX shapes are also only available in EU regions (Falkenstein, Nuremberg and Helsinki) and are not offered in Ashburn, Hillsboro or Singapore — these regions only offer the more expensive CPX and CCX lines. This cheap tier exists precisely because Hetzner does not over-provision it.

Hetzner Cloud Console server creation form: Cost-Optimized category shows a 'Limited availability' badge while Regular Performance and General Purpose do not — Hetzner Cloud Console — Cost-Optimized is the only server family flagged "Limited availability." Dedicated CPX/CCX shapes and Arm-based CAX shapes aren't.

This is rare elsewhere. AWS, GCP and Azure rarely display capacity errors for standard instance types in major regions because they aggressively oversubscribe and absorb the cost of maintaining spare hardware. The "soft capacity" available at AWS is not free — it is included in the per-hour rate. Hetzner's per-hour rate doesn't include this, and its billing model for stopped servers is the visible consequence of this.

Where this surprises teams

The policy itself is unambiguous, but several common workflows assume the AWS model, which can result in avoidable bills on Hetzner.

The "we'll pause it for the sprint" pattern. A team takes a snapshot of a development server before a risky migration, powers the machine off and intends to return in a week. If the work slips and the server is forgotten, six weeks later the CCX13 in Falkenstein will have accrued around €22 of charges (at the post-April 2026 rate of €15.99 per month) for doing nothing. At fleet scale, this is the largest single source of cloud-server waste that we observe on Hetzner. The solution is not to stop the server, but to take a snapshot and then delete the server itself. The snapshot retains the disk image at €0.0143/GB/month — typically a fraction of the server price.

The "stop overnight" cost-saving pattern from AWS. Engineers who have used the AWS Instance Scheduler often try the same trick on Hetzner, stopping dev servers at 18:00 and starting them at 08:00, expecting to pay roughly a third of the monthly rate. On Hetzner, however, this saves nothing. The only equivalent on Hetzner is deleting and recreating from a snapshot, which is feasible for stateless development boxes, but it introduces enough operational complexity that most teams decide it isn't worth €5–€20 per server per month.

The "scale down for a quiet period" pattern. A team upsizing a CCX23 to a CCX33 for a launch and planning to scale back down a few weeks later. They power the server off in the meantime to 'save some money during the quiet phase'. However, the downsizing is then blocked because Hetzner does not allow rescaling to a smaller disk, regardless of how full it actually is. Consequently, the powered-off month is billed at the CCX33 rate the entire time. A better approach would have been to use Hetzner's "CPU and RAM only" rescale option from the outset, which would have preserved the original disk size and downgrade path.

The underlying mistake in each case is the same: applying a state-based mental model (stopped = cheap) to a system that bills for existence (exists = paid for in full).

A short decision framework

When you find yourself about to shut down a Hetzner cloud server, work through the following steps:

Will the server be needed again in the next 24 hours? If so, leave it running. The cost of stopping is the same as the cost of running, and you avoid any boot time when you come back.
Will it be needed within the next two weeks? Take a snapshot, delete the server and recreate it from the snapshot when needed. The cost analysis for a CCX13 in Falkenstein is as follows: keeping it running costs €15.99 per month; the snapshot costs approximately €0.50–€1.50 per month for a typical 40–100 GB disk. Even if you recreate it twice a week, you will save money.
Will it be needed at all? Take a snapshot if there is any data you might want, then delete the server. Snapshots are not location-bound and can be restored to any region within the same architecture (x86 to x86, Arm64 to Arm64), per Hetzner's snapshot FAQ, so you don't lock yourself into a specific data centre.
Is this a stateful database or a server you cannot afford to lose? Snapshot-and-delete is risky if you might need the exact disk state, including in-flight processes. In that case, the honest answer is to leave it running, and you will have to pay the bill for that operational choice.

For a server you want to keep but stop paying for, the practical flow is not "stop and forget." It is: graceful shutdown, snapshot, delete, then restore from the snapshot when needed again.

The two easy-to-miss details are exactly why this takes five steps. A powered-off server is still billed at the full server rate, so "shutdown" is only a short preparation step, not a saving state. And after the snapshot is created, there is briefly a "paying for both" window until the server is deleted. The savings begin only at deletion.

The cost drop happens at deletion, not at shutdown.

It's simple: stopping a Hetzner server is not a cost-effective solution. Snapshot-then-delete is.

The bottom line

The billing policy isn't an oversight to work around; it's the explicit trade you accept when you choose Hetzner over AWS or GCP. The hyperscalers bundle the cost of hot-reserve capacity into every per-hour rate, whether you use it or not. Hetzner unbundles it and hands you the lever: keep what you need, delete what you don't, and the price stays where it is. Operators who treat "delete" as a routine action rather than a destructive one get the full value of that bargain.

CloudTally surfaces where that lever isn't being pulled — stopped servers, orphaned IPs and forgotten snapshots — so the bargain you signed up for actually shows up on the invoice.