Question 1

What counts as a billable run in Scalr?

Accepted Answer

Scalr bills two kinds of run: an apply run (plan, cost estimation, policy check and apply) and a dry run (plan, cost estimation and policy check). A plan that Scalr runs on a pull request is a dry run, so a change that gets planned in a pull request and applied after merge is at least two billable runs. Runs on self-hosted agents are billed like any other run, and the agents themselves are free.

Question 2

Which failed runs does Scalr bill?

Accepted Answer

Scalr bills a failed run when it fails during plan (for example on a provider or cloud API error), when an OPA policy stops it in the post-plan phase, or when it fails during apply. Scalr doesn't bill runs started by the drift detector's schedule, runs in workspaces that use local execution mode, runs stopped by an OPA policy or a Checkov security check in the pre-plan phase, runs that fail during terraform init (for example a missing folder or var file, a code parsing error, a registry or Docker connectivity error, or a broken provider config; Scalr's pricing FAQ says these examples aren't the full list), runs that fail during cost estimation, or runs that fail because of an internal Scalr error. In the Scalr UI, a failed run that isn't billed is marked with an icon.

Question 3

How do I estimate my Scalr run count?

Accepted Answer

Multiply the changes you apply each month by the number of plans each change gets before it merges, plus one for the apply. If you use Terraform Cloud, Scalr's open-source runs script (github.com/Scalr/terraform-scalr-migrate-tfc, tfc-runs folder) counts the runs in your account, and its --period flag limits the count to the last N days. The script counts some runs Scalr would not bill, so treat its result as an upper bound.

Question 4

What happens if I use all my prepaid runs?

Accepted Answer

Scalr never blocks a run. Once prepaid runs are used up, extra runs are billed at the flex rate of $0.99 per run at the end of the subscription period. You can upgrade or renew early at any time to avoid the flex rate. Unused runs do not roll over to the next subscription period.

Question 5

How can I keep my Scalr run count down?

Accepted Answer

Scalr has five settings that cut billable runs. Skip VCS dry runs so pull requests don't plan automatically, add [skip ci] or [skip scalr ci] to a commit message to skip a run, and set working directories or trigger patterns so only changes to relevant files start a run. Pre-plan checks such as OPA policies, Checkov, terraform fmt and terraform validate stop bad runs before the plan, and those stopped runs are not billed. State storage only mode runs Terraform on your machine and uses Scalr only for state, which suits early development on CLI-driven workspaces.

Question 6

What's the difference between the Free and Business plans?

Accepted Answer

The Free and Business plans are the same per-run product, so the only difference is volume. The Free plan covers up to 50 runs per month. Business is usage-based at $0.99 per run with volume discounts (for example, 100 runs is $99 per month). Both start with five concurrent runs by default as of September 2026, and the quota can be increased for free on request. Everything else is identical on both plans: users and environments at no extra charge, role-based access control with custom roles at the account, environment, or workspace scope, SAML 2.0 single sign-on (Okta, Microsoft Entra, JumpCloud, Google Workspace, and any other SAML 2.0 provider) at no extra charge, and the full set of core features such as drift detection, policy enforcement, and the module and provider registries.

Question 7

Is concurrency included?

Accepted Answer

Yes, at no charge. As of September 2026 every new account starts with five concurrent runs by default on Scalr's managed runners, on the Free and Business plans alike, and the quota is raised free of charge on request with a valid use case. Self-hosted agents add five concurrent runs each, decoupled from the managed-runner limit.

Question 8

Why doesn't Scalr use concurrency-based pricing?

Accepted Answer

Concurrency-based pricing sells a fixed number of parallel run slots, so the customer has to guess the right number. Too few slots and engineers queue during releases and incidents. Too many and the customer pays for idle capacity. Scalr bills per run instead, so one more run costs one more run and there is no slot count to plan.

Simple Pricing

Business

Monthly Estimate

Enterprise

What counts as a billable run?

How do I estimate my run count?

Compare Plans

Frequently asked questions

Migrate in minutes.