Waiting for 1 run(s) to finish before being queued: Why Terraform Runs Wait

If the Terraform CLI just printed Waiting for 1 run(s) to finish before being queued, nothing's broken and you haven't hit a paid limit. One run in the same workspace is ahead of yours; let it finish, discard it, or use a plan-only run, which skips the workspace queue. The near-identical Waiting for N queued run(s) to finish before starting is the one that means your organization is at its concurrency cap, and that's the only one an edition upgrade fixes.

What does "Waiting for 1 run(s) to finish before being queued" mean?

It means your run is behind another run in the same workspace, not that you've hit your organization's concurrency limit. HCP Terraform processes each workspace's runs in the order they were queued, and a run stays pending until every run before it in that workspace has finished. The number in the message is your position in that workspace queue, so "1 run(s)" means one run is ahead of you.

This message comes from the Terraform CLI's cloud backend rather than the web UI, which is why you won't find the exact string in HashiCorp's documentation. Upgrading your edition won't clear it, because the wait has nothing to do with how many slots your organization has.

Three things actually resolve it. You can wait for the run ahead to finish. You can discard the pending runs queued ahead of yours, which drops them without running them. Or you can use a plan-only run, which ignores the per-workspace queue entirely, so it proceeds even while another run is in progress and doesn't block anything else.

One more thing worth knowing if you hit this in CI: the remote backend waits indefinitely by default. If a job dies after ten minutes, that's usually the CI runner's own timeout rather than Terraform giving up.

Why are my Terraform Cloud runs stuck in the queue?

The CLI tells you which of the two limits you've hit, and the wording is almost identical:

Reaching the organization limit isn't a failure either. Subsequent runs queue and wait for a slot; there's nothing broken to fix, you've run out of slots.

When runs do reach the organization queue, it is priority-ordered: applies go first, normal plans next, and speculative plans last. That ordering is sensible, but it means a burst of plans during a release or an incident can leave a critical apply waiting behind a backlog it didn't create. Note that this priority applies to the global queue across your organization. Inside a single workspace the order is simply first in, first out.

How do you get around the Terraform Cloud concurrency limit?

On HCP Terraform, the supported path to more concurrency is a higher edition. Each edition (Essentials, Standard, Premium, and Enterprise) sets the maximum run concurrency for the organization, so raising the ceiling means moving up a tier rather than buying individual slots.

One option that looks like it should help is agents. HCP Terraform agents let runs execute inside your own network for private-infrastructure access, and your plan governs how many agents you can register. But the concurrency cap is a property of your edition, and agents don't raise it: they change where runs execute, not how many run at once.

Platforms built on usage-based pricing approach this differently. On Scalr, for example, each self-hosted agent you deploy adds 5 concurrent runs, and the base quota can be raised for free. The capacity scales with how many agents you choose to run rather than with which tier you bought.

How does concurrency-based pricing compare to usage-based pricing?

Concurrency-based pricing sells fixed parallel run slots. There's no slot count that's right: buy too few and engineers queue during releases and incidents, buy too many and you pay for capacity that sits idle most of the month. The model caps throughput during outage response, the moment teams can least afford to wait, and it turns code review into a queue too, because a plan that hasn't run yet can't be reviewed. Usage-based pricing charges only for runs that executed, so capacity isn't something you provision in advance.

Scalr figures as of September 2026, from Scalr's pricing FAQ; HCP Terraform figures as of June 2026, from HashiCorp's published documentation. Neither vendor puts its concurrency integers on its pricing page (HashiCorp's sit in its support center, Scalr's in its pricing FAQ), so treat the model, not a specific integer, as the durable fact.

How does Scalr handle Terraform run concurrency?

In 2024 Scalr decoupled the concurrency cap on its hosted runners (which exists to protect shared infrastructure) from self-hosted agents, which run on your own compute and can't put that shared core at risk. Each agent now runs up to 5 concurrent runs, and you decide how many agents to deploy. Across Scalr's user base, deployed agents rose 114% and the average wait from trigger to execution went from 39 seconds to zero. One large hardware retailer went from 15 concurrent runs to 65 with 10 agents, and its average wait across roughly 3,500 runs dropped from 5 minutes 48 seconds to effectively nothing.

As of September 2026, Scalr's pricing FAQ gives new accounts five concurrent runs by default, and the free tier covers up to 50 runs per month with the full core feature set. Each self-hosted agent adds five more, agents are unlimited and free, and the quota can be raised at no charge by opening a support ticket with a valid use case. Billing is per executed run, with overage ("flex") runs at $0.99 each, so there's no slot to mis-provision.

You shouldn't have to pick a concurrency number in advance and live with it during an incident. On Scalr you don't: deploy another agent and you've got five more slots, or ask support and the quota goes up for free. The current default and the per-agent increment are in Scalr's concurrency FAQ. For the other speed and cost levers, the Terraform optimization guide covers them.