A Terraform check block assertion failed during plan or apply. This non-blocking validation error occurs when a custom assert condition in your check block evaluates to false, indicating your infrastructure doesn't meet expected criteria.
In Terraform 1.5+, check blocks allow you to validate your infrastructure against custom conditions outside the normal resource lifecycle. Each check block contains one or more assert blocks that evaluate a condition expression. When a check block's assertion fails, Terraform evaluates the condition to false and displays a warning with the associated error_message. Unlike preconditions and postconditions, check block failures do not block Terraform from continuing execution—they are informational validations that help you verify your infrastructure meets expected standards. The "Check block assertion failed" error means one or more of your custom validation conditions evaluated to false, typically indicating a resource doesn't have an expected property, attribute value, or connectivity state.
Examine the check block in your Terraform configuration and identify which assert block failed. The error message will specify the exact check name and the condition that evaluated to false.
check "health_validation" {
data "http" "endpoint" {
url = "https://api.example.com/health"
}
assert {
condition = data.http.endpoint.status_code == 200
error_message = "API endpoint returned status code: ${data.http.endpoint.status_code}"
}
}The error_message tells you exactly why the assertion failed. Use this information to understand what needs to be fixed.
Run terraform plan and check the actual values of the resource or data source being validated in the check block. Compare the actual values to what the assertion expects.
terraform plan -out=plan.tfplanLook at the plan output for the resource referenced in the check block. Verify:
- Does the resource have the expected attributes?
- Are the attribute values what the assertion expects?
- Is the data source returning the expected values?
Update your Terraform configuration to ensure the resource or data source will satisfy the assertion condition. This is the actual fix—the check is only reporting the problem.
For example, if a check asserts that an AWS load balancer has deletion protection enabled:
resource "aws_lb" "app" {
name = "application-lb"
load_balancer_type = "application"
enable_deletion_protection = true # Add this to satisfy the check
}Or for a health check that expects a 200 response:
check "api_health" {
data "http" "health" {
url = "https://api.example.com/health"
}
assert {
condition = data.http.health.status_code == 200
error_message = "API health check failed: status ${data.http.health.status_code}"
}
}Ensure your actual API is running and returns a 200 status code.
If your check block uses nested data sources to validate external endpoints or services, ensure those services are accessible and return expected values before running terraform apply.
# Test the health endpoint manually
curl -v https://api.example.com/health
# Verify DNS resolution
nslookup api.example.com
# Check network connectivity from your Terraform environment
terraform refresh # Refresh data sourcesWait for the external service to be ready if it's being created by the same Terraform configuration, since check blocks run as the final step.
After fixing the underlying resource configuration, run terraform plan again to verify the assertion now passes, then apply the changes.
terraform plan
terraform applyThe check block will run as the last step. If the assertion still fails, the error will be displayed as a warning, but Terraform will continue. Review the warning and adjust the resource configuration further if needed.
Check blocks execute as the final step of terraform plan and apply operations, after all resources have been planned or provisioned. This means check blocks can use nested data sources to validate infrastructure state after apply.
Unlike preconditions and postconditions, check block failures are non-blocking—they don't prevent Terraform from continuing execution. This makes them ideal for optional validations and infrastructure health checks.
Check blocks are only available in Terraform 1.5.0 and later. If you need this feature, ensure your Terraform version is >= 1.5.0 by specifying the required version constraint in your configuration.
For critical validations that must block Terraform execution, use preconditions on resources or postconditions instead of check blocks.
Error: Error rendering template: template not found
How to fix "template not found" error in Terraform
Error: Error generating private key
How to fix 'Error generating private key' in Terraform
Error creating Kubernetes Service: field is immutable
How to fix "field is immutable" errors in Terraform
Error: Error creating local file: open: permission denied
How to fix "Error creating local file: permission denied" in Terraform
Error: line endings have changed from CRLF to LF
Line endings have changed from CRLF to LF in Terraform