Skip to content
Calcrivo

Terraform Refresh Duration Calculator

Estimate how long a Terraform state refresh will take based on resource count, API latency and parallelism.

Inputs

resources

Number of resources Terraform must query to refresh state.

seconds

Average time for one provider API read call.

workers

Terraform's `-parallelism` setting (default 10).

Estimated Refresh Time

16ms

Estimated Refresh Time

0mmin

Sequential Time (No Parallelism)

2h 40ms

Parallelism Speedup

10×

Step by step

  1. Refresh time: resources × avg call time / parallelism

    200 × 0.8s / 10

    = 16.0s

  2. Sequential time (no parallelism, reference)

    200 × 0.8s

    = 160.0s

How it works

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

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.

You might also need