When your Hetzner server type is sold out

When your server type is sold out where Hetscale tries to create a server, it tries the node group’s other locations inside the load balancer’s network zone, then, if you choose a fallback mode, up to three types you list in your order or the cheapest fitting types in stock within a price cap you set. When nothing is available, the group is short of capacity until stock returns; the servers that run are not touched, and you are notified.

How does Hetscale know a type is sold out?

Hetzner’s API says, per server type and location, whether the type can be ordered now, and whether it is retired there for good. Hetscale reads this once a minute from its own Hetzner project and shares the result with every customer, so your project spends none of its API budget on stock. Hetzner marks its Cost-Optimized plans, CX and the Arm CAX, as limited: they run on older hardware generations, so the number of available servers is limited. Hetzner sells Arm only as CAX, so an Arm group has only other CAX types to fall back to. Regular Performance (CPX) and General Purpose (CCX) types can sell out too, usually briefly and in one location at a time. Hetzner calls the reading an indicator, not a guarantee. Hetzner support confirmed in October 2026 that it is updated periodically, not in real time: a create can succeed while the reading says unavailable, or fail while it says available, so the answer to the create is what counts.

A reading older than 3 minutes is ignored, and a stale reading is never a reason to stop scaling: Hetscale then tries the create anyway, at most once per group and step every 5 minutes. An outage of the stock poll alerts Hetscale’s operator and never blocks your group.

Hetzner’s answer to a create stays the truth: a type it cannot supply is refused with 412 resource_unavailable. When a create is refused for a type and location Hetscale’s reading calls available, Hetscale reads your project’s own server type list once, because an account Hetzner restricts gets the same 412 while its own reading shows the type unavailable there (Hetzner support, October 2026). If your project’s reading says available too, the reading has not caught up with the stock: the pair is suspect for your project until Hetzner’s reading next changes (at most 20 minutes), so your groups skip it instead of hitting the same refusal, and once a second project meets such a 412 there, every customer’s groups skip it. If your project’s reading says unavailable, the refusal is a restriction of your account (see below), never a stock-out for other customers. A server created where the reading said out of stock marks the pair available for everyone until Hetzner’s reading next changes or a create there is refused, at most 20 minutes.

What happens when my type is out in my location?

The fallback chain runs: the locations of the load balancer’s network zone, in the order of the group’s template, your seed’s location first. A Hetzner load balancer can only reach targets in its own network zone, so another zone is never tried. In a fallback mode, the chain then tries the same locations for each fallback type in turn: your types in the order you listed them, or up to three of the cheapest fitting types in stock within your cap, cheapest first.

Ashburn, Hillsboro and Singapore are each the only location of their network zone, so a group there has no other location to try, and only a fallback type helps while its type is out. Falkenstein, Nuremberg and Helsinki form the eu-central zone and are tried in turn, the seed’s location first (Hetzner’s locations page, read October 2026).

A type and location that the stock reading shows as out of stock, or that was refused recently, is skipped without a call to Hetzner, and a retired pair is not in the chain at all, nor is a type Hetzner no longer lists in any location: a fallback mode then goes straight to its fallback types. Refused and skipped steps do not count against the group’s cost guard; only servers Hetzner accepted do.

Every step is recorded on the group’s Capacity & cost page: its time, the server, the type and location, the step, the outcome and the Hetzner action, for example “Out of stock (412)”, “Skipped: out of stock” or “Skipped: a recent 412”.

Can it use another server type?

Only if the group opts in. Under “When the type is out of stock” on the group’s Settings page, or before Live with Stock fallback on its Go Live page from release v1 on, choose one of three modes:

• “Wait for the group’s type and create the server as soon as it is back”, the default.
• “Until the group’s type is back, try the types I pick, in order”: up to three types, in the fields “First type”, “Second type (optional)” and “Third type (optional)”.
• “Until the group’s type is back, use the cheapest fitting type in stock”: you set a “Price cap”, in whole euros from 1 to 1,000 a month per server. Hetscale tries up to three of the cheapest fitting types in stock whose monthly price is at most this much above the group’s type. A type above the cap, or one Hetzner’s catalogue does not price, is never used. A change to the cap applies from the next create.

A type fits when it has:

• the same architecture, x86 or Arm, because a snapshot boots only on its own architecture;
• at least the same cores, memory and disk as your type;
• a dedicated vCPU when your type has one;
• a sale in one of the group’s locations.

In both fallback modes the settings compare the fitting types with the group’s own type, shown above the modes. Each row gives the type, its vCPU, RAM and disk, its price a month with the difference per server from your type, “Now” (in how many of the group’s locations it can be ordered now, such as “2/3”, with one line per location on hover), and “24 hours” and “7 days” (its best location’s share, “Collecting” while the history is short). With your own list, the last column, “Recommended”, marks up to three priced types that were in stock at least 95 % of the last 7 days, cheapest first, or the “Most available” ones when none reaches that bar; it is shown, never applied. With the cheapest mode, the last column, “Would try now”, shows the order Hetscale would try at this minute under the cap you typed, and for the rest “Above the cap”, “Out of stock” or “No price”.

Every server counts as one unit of capacity. While a server of another type counts, the CPU rules also read the busiest server of your own type: a CPU scale-out rule also holds when that server stays at or above the threshold for the window, and a CPU scale-in rule also needs it below the threshold.

Servers move back up the order of preference: the group’s type first, then your list in its order, or cheaper before dearer in the cheapest mode. When a more preferred type can be ordered in one of the group’s locations, the least preferred fallback server gets a replacement of the best more preferred type in stock, one server at a time; once the replacement serves, the old server leaves through the drain window, inside the hour it has paid. A server only moves up, so servers never swing back and forth between types. The way back runs in every mode: after you switch to the wait mode, servers left from another mode return to the group’s type. While the group is held for maintenance, the way back waits too: no replacement is asked for, and a fallback server whose replacement already serves stays until the hold ends.

At a scale-in the least preferred type leaves first: with your list, the last listed type first, and a type no longer in the list before all of them; in the cheapest mode, the dearest first; in the wait mode, any server of another type first. Within a type, the usual order follows (When in the hour does a server leave?).

What if nothing is available?

The group is in capacity deficit, a condition, not a state: the group stays Live. Its shortfall is the servers it should run, minus those serving and those on their way. The missing server waits as Requested, and every minute Hetscale checks the stock again and tries the first step that has become available; now and then it also tries a create even when every location reads as out, in case the reading is wrong. There is no give-up timer. For a type Hetzner no longer sells in the zone, no stock comes back: the deficit’s mails say so instead of that the group waits for stock, and name what would help in the group’s fallback mode: choosing one, listing a type Hetzner still sells, or raising the price cap. The deficit ends when the servers are created, when load falls and the policy needs fewer, or when you pause the group or change its template.

While a create waits, the policy asks for no further scale-out. A replacement for a failed server waits the same way, and a stock refusal never counts as a failed healing. The servers that run keep running: a deficit only means the missing ones wait.

You are notified when a deficit starts and when it ends, with the step that succeeded, and again if it lasts; never once per attempt. After the episode, an incident report on the group’s timeline shows what happened, and the Capacity & cost page shows the time the group was short, in server-minutes.

Can a scale-in wait while my type is out of stock?

Yes, if you turn it on. Keep servers while ‹type› is out of stock, under Advanced on the group’s Settings page, is off by default. While it is on, and a stock reading from the last 3 minutes shows every type and location the group’s next create would try as out of stock or no longer sold, the group’s scale-in waits, so the group still has the server when the load comes back. Hetzner bills the server meanwhile.

• One stock-out holds scale-in for at most 24 hours; after that the group scales in as usual until a fresh reading finds stock again.
• Without a fresh stock reading, the group scales in as usual.
• It never keeps the group above its maximum. A schedule’s ceiling, a lower Max and Set the server count still remove servers. Turning the setting off ends the wait at once.
• In Propose mode, no scale-in is proposed while it waits.
• The timeline records when a scale-in starts and stops waiting for stock, and the monthly summary counts the time.

Am I told when another type stands in?

Yes, in the alert digest, never once per attempt. When the first server of another type in an episode is created, the mail says: “‹type› was out of stock, so Hetscale created ‹other type›, a type you allowed, at +€‹difference› a month per server. It is replaced once ‹type› is back.” When none is left, it says: “The group runs on its own type again.” A Hetscale restart within 10 minutes continues the episode without a new mail. The group’s timeline shows the same two moments as “A fallback type stands in” and “Back on the group’s own type”.

Am I told when Hetzner stops selling my type?

Yes. When Hetzner gives a date after which it stops selling the group’s type in the group’s locations, or a type your ordered list names, the timeline records it and you get a notice mail, and a second one once the date has passed. Before release v1, the seed’s type is watched the same way. Until a fallback mode answers it, the group’s Overview shows the date with a link to where you choose one: Stock fallback on the Go Live page before Live, the Settings page after. The day-0 report’s stock section names the date, and the preflight of Take release v1 warns while it is still ahead. Running servers keep running; new ones then need a fallback type or a new seed. A type Hetzner removes from its list altogether gets no date and no notice: the stock section, the group page and the deficit mails name it instead.

What does the group page recommend?

The group page shows the stock of your type in the zone, location by location, in the fallback order: whether each sells it now, and for how much of the last 30 days it did (“Collecting” until the history covers the period). The type’s availability in the zone is its best location’s share.

When the type is out of stock or retired somewhere now, or was often unavailable, the page names:

• the locations where Hetzner no longer sells it, saying that no stock returns there;
• the order the locations sold it in, each with its share of the last 30 days, when that differs from the group’s order. It is information only: no setting orders the locations yet;
• in Ashburn, Hillsboro or Singapore, where no other location can stand in, a fallback mode and where to choose it, for a group that waits for its own type;
• the cheapest same-or-stronger type of the same architecture that was available most of the time, with its price difference per server and month at Hetzner’s net list prices, or the most available one when none reaches that bar;
• Keep servers while ‹type› is out of stock, while the type was available less than 95% of the last 30 days in its best location and the group does not keep its servers yet (Can a scale-in wait while my type is out of stock?).

With your own list of types, a type already in the list is not suggested again. In the cheapest mode, the page names no type, because the mode picks it; the order of the locations stays.

The Capacity & cost page also shows what one more server always on would have covered, with its monthly price. Recommendations are shown, never applied: switching on a fallback type spends your money, so Hetscale never does it for you. The cheapest mode is not an applied recommendation: you choose it and set its cap, and Hetscale never spends above the cap. Fallback is a safety feature and is in every plan.

What does this not cover?

• Hetscale cannot create capacity Hetzner does not have. It does not reserve capacity and never lends its own servers: stock-outs hit every customer at once, so a shared pool would be empty exactly when it is needed. A server that runs all the time is capacity you set with the group’s minimum.
• A weaker type, another architecture or another network zone is never used. A group that waits for its own type can stay short as long as that type is out everywhere in the zone; in a fallback mode, as long as its fallback types are out too.
• A location Hetzner closes to your account alone. Hetzner’s Cloud FAQ names “A specific location has been temporarily deactivated for some customers” as one reason a server cannot be ordered, and says affected customers cannot create servers there for a while (Hetzner Cloud FAQ, read October 2026). Since 26 June 2026, Hetzner’s status page has also listed “Limited availability of cloud instances”, which restricts new customers and some existing customers chosen at random (read 5 October 2026, still listed 18 October 2026). According to Hetzner support (October 2026), a restricted account may get the same 412 resource_unavailable, and the availability Hetzner’s API reports for that account’s own project reads unavailable too. After a refused create Hetscale reads your project’s own list; when it shows the location unavailable while Hetscale’s reading shows it available, and a later refusal confirms it, your groups skip that location for a while. The group’s Timeline says once that Hetzner restricts your account there, and the Capacity & cost page shows the skip as “Skipped: your Hetzner account is restricted here”. Other customers’ groups are not affected. The zone’s other locations are still tried; Hetzner support can lift the restriction, and the first server created there afterwards ends the skip.
• The distance to your database. A server created in another location of the zone runs there: Falkenstein and Nuremberg are in Germany, Helsinki in Finland. A database next to the seed is then further from that server than from the seed. No setting keeps a group to the seed’s location, and the wait mode still tries the zone’s other locations.
• A replacement for a failed server follows the same chain: What happens when a server dies.
• Servers that waited for stock are left out of the Time to Capacity on the Capacity & cost page: How fast is a scale-out.