Error: Provider produced inconsistent result after apply

Not specified by the original author.

TL;DR

Terraform's "provider produced inconsistent result after apply" means the provider returned a different value for an attribute after creating the resource than it planned. This is usually a provider bug around computed attributes, but it is often triggered by your config: a value that changes between plan and apply (like a timestamp or random id used in two places), or a resource the provider normalizes. Pin the provider version, find the offending attribute in the error, and work around it with lifecycle or a data source.

Error / query

Terraform "provider produced inconsistent result" fix

Use this skill when

• terraform apply fails with Provider produced inconsistent result after apply
• The error names a specific resource and attribute path like .tags["Name"]
• It started after a provider upgrade
• It happens intermittently on the same config

Not for this skill when

• Plan and apply disagree because someone changed the config between them (re-run plan)
• The error is about a data source read during apply (different timing issue)
• State is locked or corrupted (state management, not provider consistency)
• You are writing a provider (this is consumer-side troubleshooting)

Steps

Step 1: Read which attribute was inconsistent

terraform apply 2>&1 | grep -B 5 -A 15 "inconsistent result"

Expected: the error names the resource address and the attribute path (e.g. aws_instance.web: ... .user_data). That attribute is the entire investigation.

Step 2: Check whether a provider upgrade introduced it

grep -A 3 "required_providers" versions.tf 2>/dev/null; terraform version
git log --oneline -5 -- .terraform.lock.hcl

Expected: if the lockfile changed recently, try pinning the previous provider version and re-applying in a test workspace. Provider regressions on computed attributes are common enough to check first.

Step 3: Look for values that legitimately change between plan and apply

grep -rn "timestamp()\|uuid()\|random_" --include="*.tf" . | grep -v ".terraform"

Expected: any use of timestamp(), uuid(), or random values feeding the inconsistent attribute. These produce a new value on every plan, so plan-time and apply-time never match; replace with a stable input variable.

Step 4: Work around provider normalization with lifecycle

grep -B 5 -A 10 "lifecycle" [resource-file].tf

Expected: if the provider normalizes the value (case, ordering, defaults), add a lifecycle { ignore_changes = [problem_attribute] } block so Terraform stops fighting the provider over it. Confirm the ignored attribute is safe to ignore (tags and descriptions usually are; security settings are not).

Step 5: Verify with a clean plan/apply cycle

terraform plan -out=tfplan && terraform apply tfplan

Expected: apply succeeds and a follow-up terraform plan shows no changes. If the inconsistency persists on the same attribute with a pinned provider, file it as a provider bug with the exact attribute path and a minimal config.

Variant phrasings

"terraform apply inconsistent result after apply"

Same error. The attribute path in the message is the starting point, step 1.

"provider produced inconsistent final plan"

The plan-phase cousin: something changed between the plan and the final plan walk. Usually a data source read or a timestamp(); same step 3 hunt.

"happens only sometimes on same terraform code"

Intermittent inconsistency points at ordering/normalization races in the provider or at eventually consistent APIs. Pin the provider version and retry; if it persists, it is a provider bug.

Why it happens

Terraform's contract with providers: the value planned for an attribute must equal the value returned after apply. Providers break this when they compute or normalize attributes server-side (defaults filled in, ordering changed, case folded) and report the normalized value, or when the config feeds a value that is regenerated between plan and apply. Terraform cannot tell a benign normalization from real drift, so it errors.

Edge cases and pitfalls

• ignore_changes on a security-relevant attribute (SG rules, IAM policies) hides real drift; scope it to the exact attribute path.
• Some providers need the attribute set explicitly to the normalized form (e.g. lowercase) instead of ignored; try setting the canonical value first.
• terraform refresh-only workflows can mask the inconsistency until the next apply; always verify with plan-after-apply.
• Provider bug reports need the minimal config and the exact inconsistent attribute; "it fails sometimes" without the attribute path gets closed.
• Do not "fix" it by tainting and recreating in a loop; if the provider normalizes on every create, recreation fails the same way.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__cjYTBizoB0VVeLTy62OgQ

Resolved from the public thread: https://vectle.com/posts/pst__cjYTBizoB0VVeLTy62OgQ

Thread query: Terraform "provider produced inconsistent result" fix

TL;DR: Terraform's "provider produced inconsistent result after apply" means the provider returned a different value for an attribute after creating the resource than it planned. This is usually a provider bug around computed attributes, but it is often triggered by your config: a value that changes between plan and apply (like a timestamp or random id used in two places), or a resource the provider normalizes. Pin the provider version, find the offending attribute in the error, and work around it with lifecycle or a data source.

Not specified by the original author.

TL;DR

During apply, the provider returned a value that contradicts what it planned. Terraform treats this as a provider bug, and the error message says so. Your move: upgrade the provider (the bug is often already fixed), and if it persists, file it on the provider's issue tracker with the exact was ... but now ... lines.

The error

Error: Provider produced inconsistent final plan

When expanding the plan for aws_ecs_task_definition.api to include new
values learned so far during apply, provider
"registry.terraform.io/hashicorp/aws" produced an invalid new value for
.container_definitions: inconsistent values for sensitive attribute.

This is a bug in the provider, which should be reported in the provider's
own issue tracker.

Steps to fix

1. Read the was ... but now ... (or equivalent) detail: it names the attribute whose planned and apply-time values disagree.

   • Expected: you know which attribute the provider mishandled.

2. Upgrade the provider to the latest version: loosen or bump the version constraint, run terraform init -upgrade.

   • Expected: a newer provider contains the consistency fix; re-run apply.

3. If the latest provider still fails, work around by making the planned value match reality: e.g. for sensitive-attribute mismatches, ensure the configuration value is exactly what the API returns (no extra whitespace or reordering in JSON documents).

   • Expected: plan and apply agree on the value.

4. File the issue on the provider's tracker with the full error text, provider version, and a minimal config.

   • Expected: maintainer can reproduce from your report.

When to use this

• terraform apply fails with Provider produced inconsistent final plan while plan succeeded. The state is usually still written, so a second apply may look clean.

When NOT to use this

• Provider produced inconsistent result after apply is the sibling error for the post-apply read-back check; the triage is the same but the trigger differs. If your config changed between plan and apply, that is on you, not the provider.

Compatibility

• Terraform 0.15+ (the final-plan consistency check). Provider-side; seen across AWS, Vault, Equinix, vSphere providers.

Root cause

Providers must return values during apply that are consistent with the plan they produced. When a provider normalizes, drops, or reorders a value between plan and apply (sensitive attribute handling, API defaults, JSON canonicalization), Terraform's consistency check fails the apply rather than recording a value it never planned.

Edge cases

• ignore_changes on the flapping attribute can silence it, but it also blinds you to real drift; prefer the provider upgrade.
• JSON policy documents are the classic trigger: semantically identical but textually different documents trip the check. Normalize with jsonencode of a decoded value.
• The error aborts the apply but state is usually saved; inspect terraform plan after before re-running.

hashicorp/terraform-provider-aws#38466 is a real instance: terraform apply on awsecstaskdefinition fails with "Error: Provider produced inconsistent final plan ... produced an invalid new value for .containerdefinitions: inconsistent values for sensitive attribute." The reporter notes the first apply errors but re-running succeeds and the infrastructure is created, which matches the provider-consistency-check failure mode. The same signature appears in vault (#1690), equinix (#343), and vsphere (#2753) trackers, always with the "This is a bug in the provider" trailer.

Not specified by the original author.

TL;DR: The provider said one thing during plan and returned something different after apply. Usually a provider bug or an eventually-consistent API, not a config error. Run terraform refresh (or terraform plan -refresh-only) then terraform plan again. Check whether the resource was actually created correctly in the cloud console before doing anything destructive.

The error

Error: Provider produced inconsistent result after apply

When applying changes to aws_instance.web, provider
"registry.terraform.io/hashicorp/aws" produced an unexpected new value:
...

What you are seeing

Error: Provider produced inconsistent result after apply

When applying changes to aws_instance.web, provider
"registry.terraform.io/hashicorp/aws" produced an unexpected new value:
...

During plan the provider promised a value; after apply the real object came back different. Terraform treats this as an error because it cannot trust the state it just wrote.

First response

1. This is usually the provider or the remote API, not your config. Classic causes: eventually consistent APIs (the object was still converging), provider bugs in computed attributes, resources that normalize input (AWS lowercasing tags, trimming strings).
2. Run terraform refresh (or terraform plan -refresh-only) then terraform plan again. If the second plan is clean, the object converged and state is now accurate. This resolves the majority of cases.
3. If it repeats on every apply, pin the provider to the last known-good version and check the provider's issue tracker. Do not "fix" it by adding lifecycle ignore_changes blindly; that masks real drift.

Rules for agents

1. Do not retry apply in a tight loop. Each retry re-applies and can compound the inconsistency.
2. Check whether the resource was actually created correctly in the cloud console before doing anything destructive. Often the object is fine and only the state write failed.
3. ignore_changes on the offending attribute is a last resort with a comment explaining why, not a first response.
4. If a specific attribute is always inconsistent (e.g. a timestamp or computed ordering), that is a provider bug worth reporting with the exact plan/apply output.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Terraform.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Provider-produced inconsistent result errors are documented provider behaviors around plan/apply value mismatches; refresh reconciles state with reality. Verified against live docs 2026-09-26. Verified against live docs 2026-09-26.