Terraform Refresh Duration Calculator

Estimate how long a terraform refresh will take based on resource count and API latency.

About Terraform Refresh Duration Calculator

Every `terraform plan` and `apply` refreshes each tracked resource's real-world state via a provider API read call, unless `-refresh=false` is set. Formula: time = resources × avg_api_call_time / parallelism, with Terraform's default parallelism of 10 concurrent operations. Provider API rate limits, not raw resource count, are often the real ceiling on how much increasing parallelism helps.

Formula

refresh_time_sec = (resources × avg_api_call_time_sec) / parallelism

resources: Total resources to refresh
avg_api_call_time_sec: Average provider API read call duration (seconds)
parallelism: Terraform -parallelism setting

Worked example

With the default values below, Terraform Refresh Duration Calculator returns Estimated Refresh Time of 16m. Change any input above and every figure here is recalculated in your browser.

Inputs used

Total Resourcesaccepts 0–10,000,000 resources: 200 resources
Avg API Call Timeaccepts 0.01–3,600 seconds: 0.8 seconds
Parallelismaccepts 1–1,000 workers: 10 workers

Results

Estimated Refresh Time: 16m s
Estimated Refresh Time: 0m min
Sequential Time (No Parallelism): 2h 40m s
Parallelism Speedup: 10 ×

Step by step

1Refresh time: resources × avg call time / parallelism= 16.0s
2Sequential time (no parallelism, reference)= 160.0s

Assumptions and limits

The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

Why does refresh get slower as infrastructure grows?

Refresh time scales roughly linearly with resource count divided by parallelism — as you add resources without increasing parallelism or splitting state, each plan/apply takes proportionally longer just to read current state.

Does increasing `-parallelism` always help?

Only up to your cloud provider's API rate limits — pushing parallelism higher than the provider can sustain just shifts the bottleneck to throttling/retries rather than genuinely speeding up the refresh.

Can I skip refresh to speed up plan/apply?

Yes, `-refresh=false` skips the read step entirely, trading accuracy (you may plan against stale state) for speed — useful for quick iterative testing, risky for the final apply before a real change.

How do I reduce refresh time structurally?

Split large monolithic state into smaller root modules so each plan/apply only refreshes the resources relevant to that module, rather than your entire infrastructure footprint.