Hetzner Cloud billing explained: hourly, monthly, and the invoice

You opened the first Hetzner Cloud invoice and a few things did not match what you expected. There is a charge for a server you deleted three weeks ago. A primary IPv4 address has its own line, separate from the server it belonged to. The total looks like an hourly rate times some number of hours, with a monthly cap line you were not sure how to read. Down the side of the PDF, there is a reference to a "detailed consumption statement" you have not opened yet.

None of it is wrong. Hetzner's billing model is mechanical and well-documented, but it rests on four rules that do not always align with habits from AWS or flat monthly contracts. Once you know the four rules, the invoice stops being surprising. You can predict next month, and you can read the current month line by line.

The short version. Hetzner Cloud bills hourly up to a monthly cap and rounds every partial hour up to a full hour. Invoices are sent in arrears for the previous calendar month, and every resource that exists in your project is billed regardless of whether it is running or attached. Stopping a resource does not stop the bill; only deletion does. A deleted resource still appears on the next invoice because that invoice covers the month it was alive.

The four rules behind every Hetzner Cloud invoice

Everything on the invoice derives from four billing rules. Read them once and the rest of the page makes sense.

Hetzner bills hourly, never more than the monthly cap

Every Cloud server, primary IP, volume, snapshot, and floating IP has a published hourly rate and a published monthly cap. Hetzner's Cloud billing FAQ states the rule plainly: "We will bill you for the minimum amount, whether that is the monthly price cap or the hourly price multiplied by the number of hours you used the server. Your server's bill will never exceed its monthly price cap."

A CCX13 in Falkenstein has a €15.99 monthly cap and an hourly rate of roughly €0.0238 per hour. Run it for 100 hours and you pay €2.38. Run it for the whole month (about 720 hours, which would compute to over €17 at the hourly rate) and you pay €15.99. The cap is what makes a long-running server predictable.

The cap is per resource and per month. If a server is deleted in the middle of the month, the cap does not apply; you pay only for hours of existence. Create the same server twice in the same month and each instance has its own cap.

Partial hours round up to full hours

Hetzner: "We always round up the hourly usage of a server. If you create a server just for a few minutes, we will still bill you for one whole hour."

This applies to every Cloud resource billed by the hour. Create a server at 14:55 and destroy it at 15:05, and you have used parts of two hours: you are billed for two. Run a 10-minute load test, get one hour. Cycle a CI runner three times in an hour: you pay for three hours total.

Ten minutes of actual use, two full hours billed.

The cost is small for any single event. However, it adds up for processes that involve rapid creation and deletion of short-lived servers, snapshots and floating IPs, or frequent failover script reassignments. Each cycle becomes a full hour of billing.

Billing is retroactive: the invoice is for last month

From Hetzner's payment overview: "Our billing is retroactive. You will receive the invoice in the billing month after you use the product. If you order a product on May 15, for example, it will appear on your invoice for June."

The invoice dated 1 June covers May. The invoice dated 1 July covers June. Each Hetzner account is assigned its own fixed billing day at account creation, and the monthly invoice is issued on that day every month. Across all customers this means Hetzner sends invoices throughout the month rather than on one shared day, but for any given account the invoice date is consistent month to month. The invoice still settles the completed calendar month of usage that ended before it was issued.

This is the rule most often mistaken for a billing error. A resource you deleted on 28 May appears on the June invoice, correctly, because June's invoice covers May, and the resource existed for most of May. A truly final charge for a deleted resource shows up exactly once, then disappears.

A resource bills for as long as it exists, not as long as it runs

Hetzner's billing FAQ is direct on this: "Until you, the customer, delete your servers, we will bill you for them, regardless of their state." The same logic extends across most billable Cloud resources. Hetzner's console cancellation docs put it generally: "Many resources incur costs even if you do not actively use them (such as Cloud servers, floating IPs, volumes). We will invoice you for them as long as they exist."

The working rule, in five words:

If it exists, it will be billed.

Powering off, detaching, or unassigning is not a billing state. Only deletion is.

Each resource type applies the rules slightly differently

The four rules play out a little differently on each resource. The differences are where invoice surprises tend to live.

Servers

A Cloud server is billed hourly at its published rate, capped at the monthly price. The clock starts at creation and stops at deletion. Powering off does not stop it. A CCX13 powered off "for the sprint" costs the same as a CCX13 under production load. For most restart windows beyond a day, a snapshot-and-delete pattern is cheaper than a stopped server; Why Hetzner charges for stopped servers walks through the trade-off in detail.

Primary IPv4 addresses

Since February 2024, every primary IPv4 has been billed as a separate resource at roughly €0.50 per month per address, regardless of whether it is attached to a running server. IPv6 is included at no charge. The most common surprise is an IP that survives the server it was created for: deleting a server does not delete its primary IPv4 unless you explicitly opt in at the deletion dialog. Every orphan IP is a small recurring line on every future invoice until it is removed.

Floating IPv4 addresses

A floating IPv4 is roughly €3 per month, billed whether or not it is attached. A floating IP held in reserve as a high-availability failover address that is never triggered still costs €36 per year. Floating IPv6 ranges are free.

Volumes

Volumes are billed per GB per month at a published rate. Detached volumes bill at the same per-GB rate as attached ones; detach is not delete. A 100 GB volume left over from a database experiment that ended six months ago is still on every monthly invoice at full rate.

Snapshots

Each Hetzner snapshot is a full compressed image of the source disk, not an incremental delta. Storage is billed per GB per month based on the compressed size, prorated for partial months. There is no automatic retention: a snapshot taken before a deployment in January is on the May invoice unless someone deleted it. A second snapshot of the same server is roughly the same size as the first, with no deduplication.

Backups

Automatic backups are a 20% flat surcharge on the server's monthly price, with seven backup slots retained on a rolling schedule. Hetzner's FAQ describes them as "a monthly flat price, which is 20% of the price of the server you activate them for." The surcharge is independent of how much data is on the disk. An empty CCX33 with backups enabled is billed the same backup surcharge as a full one.

Traffic

Each server in an EU region (Falkenstein, Nuremberg, Helsinki) includes a generous outbound traffic allowance. Only outbound traffic to the public internet is metered. Inbound traffic is free, and traffic between servers inside the same Cloud private network is free. Overage on outbound traffic is billed per server in 100 MB blocks rounded up, so unused allowance from idle servers does not offset overage on a busy one. US and Singapore regions have smaller included allowances and higher overage rates per TB. One egress-heavy server can exceed its quota while the rest of the fleet sits well below theirs.

Load Balancers

Load Balancers are billed at their own hourly rate with a monthly cap, just like servers. The clock starts when the Load Balancer is created and stops when it is deleted, regardless of whether any targets are attached. An LB11 idle in a project still appears on the invoice.

Object Storage

Object Storage has a base monthly cost (currently around €6.49 per month per Object Storage subscription) that buys an included storage allowance and an included traffic allowance. Storage beyond the included allowance is charged per TB-hour, and outbound traffic beyond the included allowance is charged per TB. The base cost is the same whether your buckets are empty or full of the included quota; it appears as its own section on the invoice rather than inside a Cloud project.

Billing follows the lifecycle, not the workload

The shape of every Hetzner billing event:

create resource          -> billing starts
resource exists          -> billing continues, regardless of power, attachment, or use
power off / detach       -> billing still continues
delete                   -> billing stops at deletion time
next month's invoice     -> still includes the month the resource existed

That last line is the source of most "but I deleted it!" support questions. The invoice is correct. The deletion stops future billing; the current invoice is settling the past.

The PDF invoice is a summary, not a full audit

The downloadable PDF gives you totals and grouped line items, but not enough to reconcile a specific charge back to a specific resource. The first page is an overview that lists subtotals by section:

a top-level Dedicated Server section, if the account has Robot servers
one section per Cloud project, named after the project
a top-level Storage section for Object Storage
a konsoleH section, if the account has shared hosting or email

Each section shows its own subtotal for the billing month. The pages after the overview repeat the same grouping as detail tables, one row per product type within each section. Rows are grouped where product, unit of measure, and unit price match, so 20 same-spec CX23 Cloud Servers in the same project become a single row with quantity 20.

A detail page on an example PDF invoice for an April 2026 billing month might look like this:

Pos	Product count	Product	Unit	Qty	Unit Price	Total
Dedicated Server (04/2026)
1	1	AX41-NVMe Dedicated Server	Hours	109	€0.0588	€6.4092
2	1	AX41-NVMe Dedicated Server	Months	1	€36.7000	€36.7000
					Subtotal	€43.11
Project "webshop" (04/2026)
3	2	CX22 Cloud Server	Months	2	€4.4900	€8.9800
4	1	CX33 Cloud Server	Hours	328	€0.0104	€3.4112
5	3	Primary IPv4	Months	3	€0.5000	€1.5000
6	1	Volume	GB-months	20	€0.0572	€1.1440
					Subtotal	€15.04

The Product count column is the key to reading this. Three patterns to notice in the example:

The two AX41-NVMe rows are two different physical servers, not one server billed twice. One server (Product count 1) ran 109 hours before being deleted; the other (Product count 1) ran the full month and hit the monthly cap. The SKU is identical but their lifetimes differ, so the rows cannot be merged.
The CX22 row groups two different servers: Product count 2, both ran a full month at the cap. Hetzner groups them because product, unit, and unit price all match.
The Primary IPv4 row groups three different IP addresses: Product count 3, each reached its own €0.50 monthly cap. The CX33 stays on its own hourly row because its unit (Hours) differs from the CX22's (Months), and it is the only one of its kind.

What the PDF does not contain: per-resource IDs, resource names, or create and delete timestamps. The detail table lists "1 Primary IPv4, Hours, 109", but not which IP address it was or which server it belonged to. To reconcile an invoice line back to a specific resource, you need the Usage preview in the Cloud Console. That view is also grouped by Cloud project, but it lists individual resources by ID and name, with the accrued amount for the current partial month. The next article in this series walks through that reconciliation step by step.

A few things worth knowing about the line items themselves:

The same product can appear with both Hours and Months lines. A server that ran long enough to hit its monthly cap shows as Months: 1 at the cap price; another server of the same type that ran only part of the month shows as Hours: N at the hourly rate. Reading the two together is how you tell which servers reached the cap.
Robot dedicated servers and Cloud share the invoice. Their setup fees and monthly rates appear in the Dedicated Server section, separate from any Cloud project. A surprise total can appear from this section and never show up in the Cloud Console's usage preview.
konsoleH shares the invoice too. Shared hosting and email products appear under their own section heading. This is easy to forget if you only think of yourself as a Cloud customer.

One account is billed once, even across multiple projects

A single Hetzner account can host any number of Cloud projects, each with its own resources, members, and API tokens. Projects are an organisational and access-control boundary, not a separate billing boundary: every project under the account contributes to the same monthly invoice. What changes between projects is grouping, not billing. Each project appears as its own subtotal section on the invoice. The Usage preview inside the Cloud Console shows the same per-project breakdown for the current month, down to individual resource IDs and names.

This matters when teams use separate projects for production, staging, and sandbox work and assume each one is "its own bill." It is not. A forgotten test server in a sandbox project lands in the same invoice as production, but you can find it in its own project section rather than mixed into a global resource list.

VAT depends on your country, not the resources you bought

VAT treatment is driven by the customer's country and VAT-ID status, not by which products are on the invoice. Three common cases:

EU business with a valid VAT ID outside Germany. 0% VAT under the reverse-charge mechanism. The invoice shows the customer VAT ID and the line "Domestic turnover is not taxable. Your VAT registration number is: [your VAT ID] - Reverse Charge!"
EU private customer or EU business without a registered VAT ID. VAT at the customer's country rate (for example, 23% in Poland, 25% in Denmark, 21% in Spain) under EU place-of-supply rules for electronically supplied services.
German customer. German VAT (currently 19%) regardless of business or private status.

Non-EU customers (for example, in the US or India) typically see 0% VAT, but the exact treatment depends on local tax rules and is worth confirming for your jurisdiction. The applicable rate and tax code appear on the first page of the invoice next to the net total.

The implication

Read the invoice in the order Hetzner wrote it. Confirm the billing month first (the invoice received in June settles May). Walk the section subtotals next, so a Dedicated Server, Storage, or konsoleH charge does not get attributed to a Cloud project. Then look at each Cloud project section: every line is a resource that existed in that project last month, for at least one rounded-up hour.

The next question is different in kind: is this specific line correct? Answering that requires resource IDs, create and delete timestamps, and an expected-charge calculation. That is the subject of the next article: how to verify a Hetzner invoice line by line using the Cloud Console's activity log and the usage preview.

For the wider pattern catalogue of where Hetzner billing surprises AWS-trained engineers, see Hetzner billing surprises: what AWS, Azure, and GCP habits get wrong. For a diagnostic walk-through when this month's invoice is already higher than expected, Why your Hetzner bill is higher than expected is the companion piece.

CloudTally tracks the resources currently in each Hetzner project (running or stopped, attached or orphan) and shows what they will add to next month's invoice. The picture matches what Hetzner is metering, so the invoice itself becomes confirmation rather than discovery.