Why can't I create a server on Hetzner Cloud?

A Hetzner Cloud server fails to create for one of four reasons: the server type is out of stock in that location, the project has reached its resource limit, the account is waiting for verification or is restricted, or the server type has been deprecated. Since 26 June 2026, the first cause has been the most common: Hetzner’s status page shows an open incident, “Limited availability of cloud instances”, and the Cost-Optimized CX and CAX types are listed as unavailable on hetzner.com as of 14 November 2026.

Quick diagnosis

The error codes and their descriptions come from the Hetzner Cloud API reference.

1. The server type is out of stock

Hetzner’s cloud FAQ lists two capacity reasons: no free resources at a location, or a location “temporarily deactivated for some customers”. In a restricted location, affected customers cannot create servers, rescale existing ones, or move servers to other accounts. Existing servers keep running. Hetzner says the restrictions lift automatically and suggests trying again the next day.

The status incident opened on 26 June 2026 explains the current situation: continued high demand and limited availability of hardware components mean Hetzner restricts new cloud servers for new customers and for some existing customers, selected at random. It states that individual requests cannot be prioritized.

The Cost-Optimized line is hit hardest. Hetzner’s Cost-Optimized page says the plan runs on older processor generations that it keeps in service, so “the number of available servers is limited”. As of 14 November 2026, every CX and CAX type on that page shows “not available”.

What to do:

1. Check which types are orderable in which location. The API returns an available flag per location for every server type:

   bash Copy

   curl -s -H "Authorization: Bearer $HCLOUD_TOKEN" \
     https://api.hetzner.cloud/v1/server_types \
     | jq -r '.server_types[] | .name + ": " + ([.locations[] | select(.available) | .name] | join(", "))'

2. Try another location in the same network zone. Falkenstein, Nuremberg and Helsinki share the eu-central zone, so private networks and Floating IPs still work across them.

3. Try another line. Regular Performance (CPX) and General Purpose (CCX) servers cost more, but are often orderable when CX and CAX are not. The shared vs dedicated vCPU article explains the difference.

4. In automation, list several acceptable types and locations instead of one, and retry later instead of failing hard.

2. The account or project hit its limit

To prevent abuse, Hetzner limits how many resources an account can create. The current limits appear on the Limits tab of the project overview in the Hetzner Console. To raise them:

1. Open the Hetzner Console.
2. Click Request change in the upper-right corner.
3. Select Limit increase and describe what you need and why.

Hetzner reviews limit requests manually during business hours and does not answer questions about them by phone. If you already have a request open, reply to that ticket instead of opening a new one. Accounts also have a default limit of 20 projects.

New accounts start with low limits, so a first Kubernetes cluster or load test often hits this before anything else.

3. The account needs verification or is restricted

Hetzner runs fraud checks on registrations and first orders. It looks closely at large or high-value first orders and may ask you to verify the account with a government-issued ID or a credit card prepayment before it processes an order. Hetzner asks new customers not to register through a VPN or with a free email address, and suggests starting with a small cloud server. An open invoice also blocks new orders until it is paid.

Two points from Hetzner’s FAQ are easy to miss. Topping up credit does not make an unavailable product available. And registration problems go to [email protected], not to the general support queue.

4. The server type is deprecated

Hetzner retires older server types on a schedule announced in its API changelog. Once retired, a type disappears from the API list endpoint, and requests that use it by name fail. Old Terraform configurations, Ansible playbooks and cluster autoscaler settings break this way.

Existing servers of a retired type keep running, and Hetzner points to the rescale option to move them to a current type. The CX Gen3 and CPX Gen2 types are described in our post on the new shared vCPU families. The older CPX11 to CPX51 types are still listed for Ashburn and Hillsboro.

Note that the CX23 to CX53 replacements are themselves Cost-Optimized types, so in late 2026 a configuration fixed for deprecation can still fail on availability.

Planning for limited capacity

Capacity limits affect production as well as first-time setups: a cluster that cannot add nodes cannot scale out or replace a failed server. The article on whether Hetzner is reliable enough for production covers how to design for it, and why Hetzner is cheap covers the 2026 price changes that came with the shortage.

For Kubernetes on Hetzner, see the Hetzner Kubernetes guide. Cloudfleet’s managed Kubernetes for Hetzner uses node auto-provisioning to pick among shared, dedicated and Arm server types, and node affinity rules can list fallback options when the first choice cannot be provisioned.