Terraform Run Concurrency: Why Runs Queue and How to Fix It

One of the main reasons teams adopt Terraform is speed: a single module can change thousands of resources across hundreds of applications. But Terraform is only as fast as the system running it, and when that system makes you wait, the speed advantage evaporates exactly when you need it. The most common cause of that wait is run concurrency.

Why are my Terraform Cloud runs stuck in the queue?

Two different limits stall a run, and they are easy to confuse because both leave it sitting in Pending. Your workspace processes its own runs one at a time, so a run waits for whatever is already running in that workspace. Separately, your organization has a maximum number of runs it will execute at once, so a run also waits when every slot across the org is busy. Only the second one is about capacity you can buy.

The Terraform CLI tells you which one you have hit, and the wording is almost identical:

Reaching the organization limit is not a failure. HashiCorp's support documentation is explicit that subsequent runs simply queue and wait for a slot, so there is nothing broken to fix; you have 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 did not 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.

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 have 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 will not find the exact string in HashiCorp's documentation. Upgrading your edition will not 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 HashiCorp documents as ignoring the per-workspace queue entirely, so it proceeds even while another run is in progress and does not 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 is usually the CI runner's own timeout rather than Terraform giving up.

What is run concurrency, and why does it slow teams down?

Run concurrency is the number of plans and applies a platform will execute in parallel. Picture pushing a change during a maintenance window or an incident, under pressure to move fast, and then sitting idle because the platform deploying your Terraform has hit its limit. The work is ready, the engineer is ready, and the only thing missing is a free slot.

This is a developer-experience problem before it is a throughput problem. Queued runs stretch feedback loops, stall code review (a plan that has not run yet cannot be reviewed), and turn a five-minute change into a twenty-minute one during the busiest part of the day.

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 HashiCorp documents maximum run concurrency as a property of your edition, and nowhere documents agents as raising it, so treat agents as changing where runs execute rather than 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 is no slot count that is actually 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 also caps throughput during outage response, the moment teams can least afford to wait. Usage-based pricing charges only for runs that actually executed, so capacity is not something you provision in advance.

Figures as of June 2026, from scalr.com/pricing and HashiCorp's published documentation. HCP Terraform per-edition concurrency numbers are documented in HashiCorp's support center rather than on its pricing page; treat the model, not a specific integer, as the durable fact.

How did Scalr cut concurrency wait time to zero?

In 2024, Scalr decoupled the concurrency applied to its hosted runners from the concurrency applied to self-hosted agents. Hosted runners keep a quota to prevent abuse of shared infrastructure, but self-hosted agents run on the customer's own compute and never put that shared core at risk, so applying the same cap to them made little sense. After the change, each agent could run up to 5 concurrent runs, and customers controlled how many agents they deployed.

The effect across Scalr's user base was larger than expected:

• The number of deployed agents rose 114%.
• Average wait time from when a run was triggered to when it executed went from 39 seconds to 0.

One of the most affected customers, a large hardware retailer, shows the shape of it. They ran 15 concurrent runs before the change. With 10 agents deployed, they jumped to 65 concurrent runs the moment the agent cap was lifted. In the 20 days before the change, they averaged a 5 minute 48 second wait across 3,670 runs, a total delay of 355 hours. Afterward, average wait across 3,330 runs was effectively zero. That pattern, less dramatic but in the same direction, repeated across many accounts.

How does Scalr handle Terraform run concurrency today?

As of June 2026, Scalr's free tier includes 2 concurrent runs and up to 50 runs per month, with the full core feature set. Paid Business starts at 5 concurrent runs. Each self-hosted agent you deploy adds 5 more, agents are unlimited and free, and the concurrency 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 is no concurrency slot to mis-provision.

The point is not that more concurrency is always better. It is that a release or an incident should never stall because of a number someone picked months earlier on a pricing page. When teams control their own concurrency, they ship faster and spend less time watching a queue. See Scalr pricing for the current run and concurrency limits by tier, or read the Terraform optimization guide for the broader set of speed and cost levers.