How to fix Error: Saved plan is stale in Terraform

TerraformINTERMEDIATEHIGHUpdated Dec 30, 2025· 190 views

The "Saved plan is stale" error occurs when Terraform detects that the state file has changed after you created a plan but before applying it. This typically happens in CI/CD pipelines or when multiple operations modify the state concurrently.

Quick fix

Fixes Error: Saved plan is stale

# Remove the stale plan file
rm tfplan

# Generate a new plan
terraform plan -out=tfplan

# Apply the new plan
terraform apply tfplan
  1. Delete the stale plan file and create a fresh one
  2. For CI/CD pipelines: avoid passing plan files between stages
  3. Investigate state changes using terraform show
  4. Refresh state if drift is detected
terraform — error
# Remove the stale plan file
rm tfplan
# Generate a new plan
terraform plan -out=tfplan
# Apply the new plan
terraform apply tfplan
Error: Saved plan is stale

What this error means

Terraform creates a plan by comparing your configuration against the current state file. The plan file is essentially a record of the changes Terraform intends to make. However, if the state file is modified by another operation after the plan is created but before it's applied, Terraform considers the plan "stale" and refuses to apply it. This safety mechanism prevents inconsistent infrastructure changes. Terraform detects staleness by comparing the state's serial number (a counter that increments each time the state is modified) between when the plan was created and when the apply operation begins. If the serials don't match, the state has changed and the plan is no longer valid.

Typical symptoms

  • Getting 'Error: Saved plan is stale' when running terraform apply with a saved plan file
  • Error message states: 'The given plan file can no longer be applied because the state was changed by another operation after the plan was created'
  • Terraform refuses to apply a .tfplan file even though it was just created
  • In multi-stage CI/CD pipelines, plan works in first stage but apply fails in subsequent stages

Common causes

  1. Another terraform apply operation modified the state file between when you ran terraform plan and terraform apply
  2. Concurrent CI/CD pipeline runs against the same state, where one run completes its apply before another run's apply begins
  3. Data sources that generate values on every run (like random_id) increment the state serial without actual resource changes
  4. Manual state modifications via terraform state commands between plan and apply
  5. In multi-workspace or multi-stage pipelines, each stage modifying shared state before all stages complete

How to fix "Error: Saved plan is stale"

1Delete the stale plan file and create a fresh one

The simplest solution is to regenerate the plan:

bash
# Remove the stale plan file
rm tfplan

# Generate a new plan
terraform plan -out=tfplan

# Apply the new plan
terraform apply tfplan

This ensures the plan is created with the current state and captures any state changes that occurred between the original plan and this moment.

2For CI/CD pipelines: avoid passing plan files between stages

In multi-stage pipelines (TEST, QA, PROD), don't save and reuse plan files across stages. Instead, create a fresh plan in each stage:

yaml
# Bad approach (prone to stale plan errors)
stages:
  plan:
    - terraform plan -out=tfplan
  apply:
    - terraform apply tfplan  # May fail if state changed

# Good approach (create fresh plan per stage)
stages:
  plan:
    - terraform plan
  apply:
    - terraform plan -out=tfplan
    - terraform apply tfplan

This ensures each apply uses a plan created from the current state at execution time.

3Investigate state changes using terraform show

If you want to understand what changed that made the plan stale, compare the old plan with a new one:

bash
# Save the original plan as text
terraform show -no-color tfplan.old > tfplan.old.txt

# Create a new plan
terraform plan -no-color -out=tfplan.new > tfplan.new.txt

# Compare the differences
diff tfplan.old.txt tfplan.new.txt

This shows you exactly what changed in the state between the two plan generations. Look for state serial increments and data source changes.

4Refresh state if drift is detected

If the state was modified due to out-of-band infrastructure changes, use refresh-only mode to sync your state:

bash
# Create a refresh-only plan (updates state without modifying resources)
terraform plan -refresh-only -out=tfplan.refresh

# Review the changes
terraform show tfplan.refresh

# Apply the refresh-only plan
terraform apply tfplan.refresh

# Now create your normal plan
terraform plan -out=tfplan
terraform apply tfplan

The -refresh-only flag is safer than the deprecated terraform refresh command because it lets you review changes before applying them.

5Disable refresh for interactive use if appropriate

If you want faster planning during development and trust your state is current, you can skip the refresh step:

bash
# Plan without refreshing state (faster, but skips out-of-band change detection)
terraform plan -refresh=false -out=tfplan

# Apply directly
terraform apply tfplan

Note: This is only safe if you're confident no external changes have been made to your infrastructure. Don't use this in CI/CD pipelines handling production infrastructure.

Advanced notes

State Serial Increments: Each time the state is modified, Terraform increments the state's serial number. This is how Terraform detects whether the state has changed. Even if the actual resource configuration hasn't changed, data sources or other state-modifying operations will increment this serial, making previously-created plans invalid.

Data Source Side Effects: Some data sources (like random_id or uuid) generate new values on every application. Even if you don't explicitly ask for new values, they may be re-generated during plan/apply cycles, modifying the state serial.

HCP Terraform Behavior: If you're using HCP Terraform (formerly Terraform Cloud), it automatically discards stale plans if another run is applied before your saved plan run is confirmed. This is by design to prevent exactly this problem.

Rootless Terraform: In rootless Terraform deployments with managed state, the state timestamps are sometimes used for staleness detection rather than serial numbers alone. Ensure your state backend is properly synchronized across operations.

Lock Files: State lock files are not the same as plan staleness. If you see "Error acquiring state lock" instead, that's a different issue related to state locking timeouts.

Frequently asked questions

What does "Error: Saved plan is stale" mean?
Terraform creates a plan by comparing your configuration against the current state file. The plan file is essentially a record of the changes Terraform intends to make. However, if the state file is modified by another operation after the plan is created but before it's applied, Terraform considers the plan "stale" and refuses to apply it.
How do I fix "Error: Saved plan is stale"?
The "Saved plan is stale" error occurs when Terraform detects that the state file has changed after you created a plan but before applying it. This typically happens in CI/CD pipelines or when multiple operations modify the state concurrently.
What causes "Error: Saved plan is stale"?
Another terraform apply operation modified the state file between when you ran terraform plan and terraform apply Concurrent CI/CD pipeline runs against the same state, where one run completes its apply before another run's apply begins Data sources that generate values on every run (like random_id) increment the state serial without actual resource changes
Is the "Error: Saved plan is stale" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading