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:

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

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

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

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

```console
$ 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:

```console
$ 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.

> [!WARNING]
> Never edit the token value directly in the cluster if you are managing objects with GitOps. Update the source secret in your Git repository so the change stays in sync.

## 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](/docs/hetzner/apalla/clusters/troubleshooting/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](/docs/hetzner/apalla/servers-and-nodes/access/server-not-provisioning), 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](/docs/hetzner/apalla/support/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](/docs/hetzner/apalla/getting-started/prepare-your-hetzner-account)
- [No servers available](/docs/hetzner/apalla/clusters/troubleshooting/no-servers-available)
- [A server that will not provision](/docs/hetzner/apalla/servers-and-nodes/access/server-not-provisioning)
- [Cluster Stacks](/docs/hetzner/apalla/concepts/foundations/cluster-stacks)
- Collect logs with the log collector
- Get support