Capacity planning on Hetzner when your server type is sold out
A sold-out Hetzner type fails with resource_unavailable and cannot be reserved. Keep your pre-June 2026 servers, keep a fallback type and rent only the peak.
- Author
- Hetscale
- Published
- Last updated
- Tags
- explainer, hetzner, capacity-planning, pricing
When your Hetzner server type is sold out, a server create fails with 412 resource_unavailable,
and nothing in your account changes that: Hetzner Cloud has no way to reserve capacity. Since
Hetzner’s price adjustment of 15 June 2026, the same new server also costs more than one created
before that date, which keeps its pre-June price until you delete or rescale it. Both facts point
the same way. Treat the servers you already run as your capacity and never give up the old ones,
keep a second location and server type ready, and rent the peak by the hour when Hetzner has it,
without counting on it.
What changed on Hetzner in 2026?
Two things, and they compound.
New orders cost more. On 15 June 2026 Hetzner raised the prices of new servers and of servers that are rescaled; servers created before that date keep their price. It was the second increase of the year: on 1 April 2026 Hetzner had raised existing servers as well, so the price an old server keeps is its April price, not the one it was first ordered at. For the cost-optimized x86 types in the EU locations, monthly net list prices:
| Type | Before 15 June 2026 | Since 15 June 2026 |
|---|---|---|
| CX23 | €3.99 | €5.49 |
| CX33 | €6.49 | €8.49 |
| CX43 | €11.99 | €15.99 |
CX types went up by 31 to 38 percent and Arm CAX types by 30 to 33 percent. Regular performance (CPX) and dedicated (CCX) types in the EU now cost 2.1 to 2.75 times what they did.
The cheapest types sell out. Hetzner describes its cost-optimized plans, CX and CAX, as running on older hardware generations with a limited number of servers, and on 6 October 2026 its page for them showed all eight types as not available. Stock comes and goes by location: in our own checks on 26 September, a CX23 could be ordered in Helsinki while it was out in Falkenstein and Nuremberg, and on 1 October it was out in all three for at least half an hour. The types that cost the least are the ones you are most likely not to get.
Why is the server you already run your best capacity?
Because it is the only server that is both cheap and certain. It keeps its pre-June price, and no stock-out can take it back. Hetzner keeps that price through a rebuild and through a move to another project with the same currency; it ends it when you rescale the server, up or down, move it to a project with another currency or restore it after deletion. Hetzner has not promised that a later adjustment will spare existing servers, so the price is a fact of today, not a contract.
Two habits follow. Never delete an old server to tidy up: a replacement costs today’s price, if Hetzner has one to give you, and some older types, such as CX22, have not been orderable at all since the start of 2026. And never rescale it, because a rescale moves it to the new price list for good. Grow beside it instead: the old servers form your base, and anything added on top is billed at today’s rate for the hours it runs.
What does “sold out” mean on Hetzner?
It means a server type cannot be ordered in one location right now. Hetzner’s API lists, for every
server type and location, whether the type is available there at the moment and whether it is
being retired, and Hetzner calls this reading an indicator, not a guarantee. The create call has
the final word: a type Hetzner cannot supply is refused with 412 resource_unavailable, which its
documentation describes as a resource that is currently unavailable, for example not available for
order. Even an accepted create can still fail while Hetzner places the server, and Hetzner can
also close a location to some customers for a while, with the advice to try again the next day.
Three constraints decide where you can go instead:
- The load balancer’s network zone. A Hetzner load balancer only reaches servers in its own
network zone. In
eu-centralthat gives you three locations, Falkenstein, Nuremberg and Helsinki;us-east,us-westandap-southeasteach have one, so a sold-out type there has no other location to try. - The architecture. A snapshot boots only servers of its own architecture. An x86 server can step up from CX to CPX or CCX; Hetzner sells Arm only as CAX, so an Arm setup can only move to another CAX type.
- The size. A fallback type needs at least the cores, memory and disk of your type, or a server that boots fine falls over at the load it was added for.
How do you plan capacity when stock comes and goes?
- Size the floor for the load you must carry alone. The servers that run all the time are the only capacity Hetzner cannot withdraw. Put the old servers in that floor, and keep at least two, so that one carries the load while the other is replaced.
- Rent the peak, and price it twice. Work out what the peak costs in your own type and what it costs in the fallback type, which may be the only one in stock on the day. In the EU a CPX32 costs €0.0569 an hour against €0.0136 for the CX33 it stands in for, about four times as much (Hetzner net list prices, October 2026), and every started hour is billed: fine for the hours of a peak, expensive for a month.
- Prepare the fallback in order. First the other locations of your load balancer’s network zone, then a type of the same architecture with at least the same resources. Decide this before the day you need it, not during it.
- Bring known peaks forward. For a launch or a sale, create the servers the day before, while stock is there, and keep them for the window. A server that already runs cannot be sold out.
- Treat “sold out” as a state, not an error. Retry later, tell someone, and never read a 412 as a reason to delete, rescale or change anything that runs.
Is autoscaling still worth it after the price increase?
The arithmetic did not change; the reason did. New servers cost more by the hour and by the month alike, so renting the peak hours instead of keeping peak servers all month saves about the same share of a bigger bill as it did before. What changed is that the cheapest capacity is now the old servers you already have, and the cheapest new capacity is the capacity Hetzner is most likely to be out of. “Cheap elastic servers” stopped being the reason to autoscale on Hetzner. “Capacity when the load needs it, and a replacement when a server dies” remained.
Whether it pays for your traffic depends on the shape of your load, not on the price change. The calculator runs the arithmetic on Hetzner’s dated list prices for your server type, your fleet and your traffic shape, and says so when the answer is to run a fixed fleet.
When should you not plan this way?
When your load is flat. If the busiest hour is close to the average, there is no peak to rent. Keep the old server, add one fixed server beside it for failures, and stop there.
When the peak must not fail. If a launch cannot go without its extra servers, do not create them in the hour you need them. Create them ahead, pay for the hours you hold them, and treat that as the price of certainty.
When you would leave Hetzner over it. We would not move a fleet that runs well because new orders cost more: the servers you have kept their price, and a move replaces all of them at once.
Where Hetscale fits
Hetscale is built around these constraints. The server you point it at joins the node group as a protected seed: scale-in never removes it and healing never replaces it, so it keeps its price. When your type is sold out, it tries the other locations of your load balancer’s network zone, then, if you allow it, up to three types you list or the cheapest fitting type in stock within a price cap you set, and moves back to your type once it returns. When nothing is in stock, the servers that run keep running, the missing ones wait, and you are told when the shortfall starts and ends. It reads Hetzner’s stock once a minute from its own project, so your API budget is not spent on it. The details are in When your Hetzner server type is sold out, and the onboarding case for campaign and e-commerce peaks covers peaks you know in advance.
Frequently asked questions
What does resource_unavailable mean on Hetzner? The server type cannot be ordered in that
location right now. Try another location in the same network zone, then a type of the same
architecture with at least the same resources, or wait and try again.
Does my old server keep its price if I stop, rebuild or move it? Rebuilding it keeps the price, and so does moving it to a project with the same currency. Stopping it keeps the price too but saves nothing, because a stopped server is billed like a running one. Rescaling it, up or down, moving it to a project with another currency or restoring it after deletion moves it to the current prices.
Can I reserve capacity on Hetzner Cloud? No. The API has no reservation of any kind. A server that already runs is the only capacity you can be sure of, and it is billed whether it is busy or not.
Which server types sell out most often? The cost-optimized CX and Arm CAX types, which Hetzner itself describes as limited; on 6 October 2026 its page showed all eight as not available. Regular performance and dedicated types can be out too, in one location at a time.
Is a CPX a good fallback for a CX? Yes, if it has at least the same cores, memory and disk: both are x86, so the same snapshot boots on it. It costs more, so use it for the hours your type is out and move back when it returns.