Summary

  • A fully created Hetzner Cloud server remains billable while it exists, including when powered off. Switching it off keeps its resource allocation.
  • Automatic backups disappear with the server; a retained snapshot can survive it. Neither includes attached Volumes, and a saved image does not reserve the next machine.
  • Seasonal projects need a price for what happens between jobs: holding an existing allocation, keeping material for reconstruction, or ending the service altogether.

“We might need it again next year” is a remarkably efficient way to order something without discussing its price. Imagine a small agency finishing an annual exhibition website. Registration has closed. The client has approved the work. The developer switches off the cloud server and moves to another job. Only the accounts department discovers that the exhibition has acquired an afterlife.

Hetzner Cloud’s billing FAQ is explicit: a server that has completed creation is charged for as long as it exists, regardless of whether it is running. Hetzner says it keeps resources allocated so the customer can start it quickly. The agency has stopped the work inside the machine. It has kept the machine’s place.

That is a comprehensible product. A customer may want an existing allocation waiting for the next call. The commercial muddle begins when the agency promises that convenience after declaring the paid project finished. A resource can be idle while the promise attached to it is working overtime.

Buying a memory instead of keeping the room

For a long shutdown, Hetzner suggests taking a snapshot, deleting the server and creating another from the snapshot later. Snapshot storage costs money too, but may cost less than holding the whole server. This exchanges one purchase for another: an allocated machine becomes a saved disk state.

For the exhibition agency, that may be exactly right. A client who wants to retain last year’s material has little reason to buy months of unused compute allocation. A client who expects registration to reopen at a stated hour is buying a different service. Someone must price the work between an archived disk and a usable website.

The phrase “we have a backup” is too roomy to settle the matter. Hetzner’s backup and snapshot documentation gives the two products different exits. Automatic backups are tied to the server and are deleted with it. Snapshots can remain. A selected backup can be converted into a snapshot before the server goes.

The agency needs to identify the copy that will actually survive its intended action. It also needs the right moment in the project’s history. A snapshot taken before the client’s final corrections does not politely absorb them afterwards. Archiving means choosing a state, not expressing general confidence that somebody saved something.

There is another boundary around the disk. The feature overview excludes attached Volumes from server backups and snapshots. If the exhibition files sit on a separate volume, saving the system disk does not pack those files into the box. A website that looks like one thing in a browser may require several decisions at closing time.

This is where a small recurring charge becomes an attractive hiding place for unfinished work. Finding the data takes time. The person who knows the layout is on a new deadline. Leaving the server alone buys the agency another month without having to settle the question. Hetzner sells the allocation; the customer also uses it to postpone a piece of its own administration.

The address has a separate tenancy

Keeping the old address adds another decision. Primary IPs are managed independently of servers. The Primary IP FAQ says an unprotected address’s auto-delete setting determines whether it goes with the server. With auto-delete disabled, it remains; enabled, it is deleted alongside the machine.

A retained Primary IPv4 remains chargeable even when assigned to no server. The billing FAQ says Primary IPv6 is free. An address on a later invoice can therefore represent a deliberate continuity purchase, not an abandoned server. It can also represent something everybody forgot. The project’s owner has to supply the explanation.

The address comes with geography. A Primary IP must be assigned to a server in the same location. Keeping it does not buy an address that can be carried to whichever location happens to have a convenient replacement. If the agency promises the old address, it has constrained its next capacity decision too.

Storage has its own finish line. Hetzner’s Console cancellation guide lists detaching a Volume and deleting it as separate steps. Disconnecting a resource does not return it. Removing one server from the inventory cannot stand in for deciding what should remain of the project.

A saved disk has not booked the next server

The most consequential difference appears when the client finally calls. A snapshot is already held. A new allocation still has to be obtained. Hetzner’s general Cloud FAQ lists account limits, lack of resources at a location and temporary restrictions affecting some customers among the reasons new instances may be unavailable. Under the temporary restrictions it describes, existing servers remain in the project.

Keeping a server therefore maintains an allocation already obtained. Deleting it saves the holding cost and puts a fresh allocation on the future work list. The disk image does not make that purchase on the customer’s behalf.

Another location might offer an alternative. The retained Primary IP remains tied to its own location, however, and Hetzner’s location guide distinguishes pricing across network zones. A saved technical state does not freeze the commercial conditions of the next order.

A disposable demonstration site can live comfortably with that uncertainty. An exhibition opening announced in invitations gives waiting a price. The useful comparison is between the cost of holding the current position and the work and timing exposure of returning later. An empty CPU graph supplies only a small part of that decision.

Our hypothetical agency’s resource inventory, waiting period and reconstruction hours are missing; those are the facts needed to calculate a break-even interval. A universal instruction to delete would be easier to print than to justify.

The bill can arrive after the guest has left

One final distinction saves an unnecessary argument. Hetzner’s billing system charges retrospectively. An invoice received after deletion can cover the period before it. The arrival of the email does not establish that the removed server is still accumulating charges.

The opposite mistake is just as easy: calling every small amount a final balance while an address or volume continues to exist. The individual consumption statement lets the agency match the resource and service period to its retention decision. That separates settling yesterday’s purchase from buying another month.

The sensible offer to the client has three versions: retain the environment, archive it with reconstruction work, or finish the service. Each can be worth buying. The bad deal is charging for the third while promising the first.

A powered-off server can be providing an honest convenience. The fiction is that nobody will have to pay for the promise sitting on it.