Cluster creation fails

If machines stay in Provisioning state for more than a few minutes after you create a cluster, start here to find the cause.

Prerequisites#

• kubectl access to the management cluster.

Check the cluster and machine status#

Run the following commands in the namespace where you created the cluster:

		$ kubectl get cluster -n <namespace>
$ kubectl get machines -n <namespace>
	

A stuck machine shows Provisioning or no phase at all. Check its events next:

		$ kubectl describe machine <machine-name> -n <namespace>
	

The Events section at the bottom usually names the cause directly. Also check the cluster events:

		$ kubectl get events -n <namespace> --sort-by='.lastTimestamp'
	

Check the Hetzner credentials secret#

Syself reads your Hetzner Cloud API token from a secret in the cluster namespace. If the secret is missing, has the wrong name, or holds an invalid token, no servers can be created.

Check that the secret exists in the right namespace:

		$ kubectl get secret -n <namespace>
	

The secret name is set in your cluster's HetznerCluster configuration under spec.hetznerSecretRef.name. Describe the secret to confirm the key names match what is set in spec.hetznerSecretRef.key.

If you use bare-metal servers, the Robot user and password live as keys (robot-user, robot-password) in this same secret, alongside the hcloud token. A separate secret, robot-ssh, holds the SSH keypair used to reach bare-metal servers through the rescue system. Check that both are referenced correctly in the HetznerCluster spec.

Check Hetzner quota and server availability#

Hetzner Cloud projects have per-region quota limits for each server type. If your project has reached its limit, the Hetzner API returns an error and no new servers are created.

Open the Hetzner Cloud Console and check the Limits section of your project to see your current usage against each quota. If you are close to the limit, contact Hetzner to request an increase.

Server types can also be temporarily unavailable in a specific location even when quota is not exhausted. See No servers available for options.

Check the SSH key#

During provisioning, Syself connects to each node over SSH. For hcloud servers, the SSH key is named in the hcloud-ssh-key-name field of the hetzner Secret, and that key must already be registered in your Hetzner Cloud project. If the name does not match a key in your project, provisioning fails at the bootstrap stage.

For a bare-metal server that never boots the rescue system or otherwise fails to install, work through A server that will not provision , which covers the robot-ssh keypair, disk wipes, and rescue-boot issues at the node level.

Collect logs for support#

If the steps above did not fix the problem, collect logs and send them to support:

1. Run the log collector on a node that did come up. See Collect logs with the log collector for instructions.
2. Send the log bundle to Syself support.
3. Include the cluster name and the output of kubectl describe cluster <name> -n <namespace>.

Related#

• Prepare your Hetzner account
• No servers available
• A server that will not provision
• Cluster Stacks
• Collect logs with the log collector
• Get support