How to fix Error: Provider produced inconsistent result after apply in Terraform
This error occurs when Terraform's provider returns unexpected values after applying changes, often leaving resources created but untracked in state. It's typically a provider bug related to eventual consistency in cloud APIs.
Quick fix
Fixes Error: Provider produced inconsistent result after apply
terraform apply- Run terraform apply again
- Import the resource into state if apply succeeds remotely
- Manually delete the resource and reapply if necessary
- Report or check the provider issue tracker
terraform applyError: Provider produced inconsistent result after apply
What this error means
Terraform applies changes to a resource and the provider successfully creates or modifies it in the remote service. However, when Terraform performs the final read operation to confirm the state, the provider returns an unexpected value or indicates the resource is missing. This happens because of eventual consistency delays in cloud APIs. The resource exists remotely but isn't immediately queryable, or the provider doesn't handle the delay properly. The most common variant is "Root resource was present, but now absent" - meaning the resource was created but the final read failed or found an inconsistency. The error is a provider bug, not an issue with your Terraform configuration. It occurs frequently when deploying new infrastructure for the first time, often resolving on subsequent apply runs.
Typical symptoms
- terraform apply fails with 'Provider produced inconsistent result' message
- The resource IS actually created in the remote service (AWS, GCP, Azure, etc.)
- Running terraform apply again succeeds without errors
- Next automated deployments fail with 'resource already exists' error
- Terraform state and remote service are out of sync
Common causes
- Provider doesn't wait long enough for the resource to become readable after creation (eventual consistency issue)
- Cloud API returns unexpected attribute values on the final read operation
- Race condition between resource creation and the provider's read operation
- Provider bug in handling computed fields or metadata changes during apply
- Timeout or connection issue during the post-apply read operation
How to fix "Error: Provider produced inconsistent result after apply"
The easiest first workaround is to retry the operation:
terraform applyIn many cases, the second apply succeeds because the resource is now stable and queryable. The resource was created despite the error message.
If the resource exists in your cloud provider but Terraform doesn't recognize it in state, import it:
First, identify the resource ID in your cloud provider (AWS console, gcloud, az CLI, etc.).
Then import it:
terraform import aws_vpc_endpoint.example vpce-12345678Replace aws_vpc_endpoint.example with your resource type and name, and vpce-12345678 with the actual resource ID.
After import, run apply again:
terraform applyIf importing doesn't work and the resource isn't critical:
1. Delete the resource manually in your cloud provider console or CLI
2. Run terraform apply again to recreate it
This only works if the resource can safely be deleted and recreated without data loss.
This is ultimately a bug in the Terraform provider (AWS, Google, Azure, etc.). Check the provider's GitHub issue tracker:
- [AWS Provider Issues](https://github.com/hashicorp/terraform-provider-aws/issues)
- [Google Provider Issues](https://github.com/hashicorp/terraform-provider-google/issues)
- [Azure Provider Issues](https://github.com/hashicorp/terraform-provider-azurerm/issues)
Search for your specific resource type and this error. If you find a related issue, add your details. If not, open a new issue with:
- Exact error message including resource type
- Terraform version (terraform version)
- Provider version
- Reproducible configuration (sanitized)
Include details like: "Error appears on first apply, succeeds on second run for aws_iam_policy_attachment"
Advanced notes
This error is pervasive across multiple Terraform providers (AWS, Google Cloud, Azure, Helm, GitHub, etc.) and is fundamentally a provider design issue rather than a user configuration error.
The root cause is that cloud providers use eventual consistency - resources are immediately accepted but take time to become fully queryable. Some providers implement retry logic to handle this; others don't. When a provider lacks proper retry logic and makes its final read too quickly, Terraform sees the inconsistency.
Long-term fix: The provider maintainers must implement exponential backoff and retry logic in their read operations after apply, or increase the initial timeout. This ensures resources are queryable before Terraform validates the state.
If you encounter this frequently on new deployments, consider adding explicit delays in your Terraform configuration using depends_on or setting provider-specific timeouts if available.
Frequently asked questions
- What does "Error: Provider produced inconsistent result after apply" mean?
- Terraform applies changes to a resource and the provider successfully creates or modifies it in the remote service. However, when Terraform performs the final read operation to confirm the state, the provider returns an unexpected value or indicates the resource is missing. This happens because of eventual consistency delays in cloud APIs.
- How do I fix "Error: Provider produced inconsistent result after apply"?
- This error occurs when Terraform's provider returns unexpected values after applying changes, often leaving resources created but untracked in state. It's typically a provider bug related to eventual consistency in cloud APIs.
- What causes "Error: Provider produced inconsistent result after apply"?
- Provider doesn't wait long enough for the resource to become readable after creation (eventual consistency issue) Cloud API returns unexpected attribute values on the final read operation Race condition between resource creation and the provider's read operation
- Is the "Error: Provider produced inconsistent result after apply" 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
- ๐Terraform Official Documentation
- ๐
- ๐
- ๐
- ๐