Documentation · Infrastructure runs

Troubleshooting infrastructure runs

A run refused over billing or a limit, one waiting on a lock, one stopped with no error of its own, and a provider that cannot authenticate: what each means.

A run that is refused, one that waits and never starts, one that runs out of time or memory, and a provider that cannot sign in: what the CLI says, and what to do about it.

When we refuse a run, terraform plan or terraform apply fails before anything executes, and the error the CLI prints includes one of the sentences below. Nothing ran and nothing was billed.

Nothing runs until a card is on file. An owner, an admin or a billing member adds one with Add a payment method on Settings → Billing, and runs start as soon as it is saved.

An invoice has gone unpaid long enough for new runs to stop. Settings → Billing shows it, with Pay now, and runs resume once it is paid. Invoices and payments has what happens on each day an invoice stays unpaid.

Something on your account's billing is stopping new runs, and the engine does not know what. Settings → Billing usually says; if it does not, email us at the address on how we support you.

The organisation in your cloud block is not one connected to your account. Check its name against the Terraform card on Settings → Integrations, and connect Terraform there if it is not connected yet.

You are at your plan's limit on open runs, with your figure in place of 20. Runs waiting for somebody to confirm an apply count, so apply or discard those, or cancel a run, and start again. Limits says what counts.

Your organisation created runs faster than we accept them. Wait a few seconds and try again.

We could not check your account, or count your runs, and refused rather than guess. Retry in a minute. If it goes on, check the status page and email us.

A locked workspace starts no new run. Its page says Locked — no new runs will start, and an owner or an admin can press Unlock.

A workspace also shows as locked while one of its own runs is going, and that is normal: a run holds the lock from the moment it is queued until it is done, including while it waits for somebody to confirm its apply. That is the usual reason Unlock is refused. Look at the workspace's runs first, and apply, discard or cancel the one holding it; the lock passes to the next queued run, or is released, as soon as it is done.

If no run of the workspace is still going and Unlock is still refused, the lock belongs to somebody else, or to a run that ended without us being able to confirm its job stopped. The page then offers Force unlock. Use it only once you know nobody is still applying, since two applies at once against the same state is what the lock exists to prevent.

A workspace applies one run at a time, so a run waits until the run ahead of it in the same workspace has finished. A run that planned and is waiting for somebody to confirm it holds the queue: apply it or discard it.

A run gets 8 GiB, and this one needed more. The message says how much it reached. Large configurations are what reach it, and splitting one across workspaces is what brings it down.

A plan, and an apply, may each run for 50 minutes. A run that reaches that is stopped, and its page in the dashboard says We stopped this run because it ran longer than a single plan or apply can run here. A run stopped sooner, with no reason given, may have met a shorter limit your organisation set itself. See limits for both, and for what to do, and run a plan before anything else if it was an apply.

A hosted run does not see your laptop's environment, your shell's variables or your local credentials files. Only what the workspace gives it reaches the run.

• With dynamic credentials, a refusal from your cloud is usually the token's subject not matching what your cloud's trust policy expects. Ours has one fewer segment than HCP Terraform's; dynamic provider credentials shows both.

• With a key, set it as an environment variable on the workspace's Variables tab, or on a variable set applied to it, and mark it sensitive. A Terraform variable and an environment variable of the same name are different things; a provider reads its key from the environment.

The configuration is larger than 10 MiB once compressed. Leave out what the run does not need with a .terraformignore file; limits has more.

The cloud block must name tf.runners.io. Pointing a configuration at us has the whole block.