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?

Almost always because the organization has hit its run concurrency limit. HCP Terraform (formerly Terraform Cloud) sets a fixed maximum number of concurrent runs per edition. When every run slot is in use, the next runs queue and wait until a slot opens. HashiCorp's support documentation describes this queueing as expected behavior, not an error, so there is nothing broken to fix; you have simply run out of slots.

The queue 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.

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, but does not raise the cap, 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. The edition's concurrency limit still applies to the organization as a whole, so adding agents changes 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 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.

	HCP Terraform	Scalr
Concurrency model	Fixed maximum per edition	Per-run billing; concurrency raised free
When you hit the limit	Runs queue and wait for a slot	Deploy a free agent for +5 concurrent runs
Entry-level concurrency	A fixed number set by the edition	2 concurrent (free), 5 (paid Business)
Adding capacity	Move to a higher edition	+5 per self-hosted agent (unlimited, free), or raise the quota free
Billing basis	Resource and run tiers by edition	Per executed run; $0.99 per overage run

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.