![How to Use Terraform Timeouts [Examples]](/_next/image?url=https%3A%2F%2Fsecure.gravatar.com%2Favatar%2F97cd5b590cff47458f92c1484f3ba9a4dddfe04172df1efc9e0f7fea6bd96683%3Fs%3D48%26d%3Dmm%26r%3Dg&w=96&q=75)
Terraform timeouts allow you to customize the duration Terraform waits for a resource operation (like create, update, or delete) before declaring it failed. By setting custom timeout values, you give Terraform a better tolerance window to succeed before failing, improving resilience and reducing false negatives during automation.
In this article, we’ll show you how to use the Terraform timeout built-in feature.
A Terraform timeout is a configurable limit that defines how long Terraform should wait for a specific resource operation (like create, update, or delete) to complete before failing.
Terraform uses timeouts to prevent operations from hanging indefinitely, especially with cloud resources that may take longer than expected. Timeout values can be adjusted based on expected provisioning times for specific resource types or cloud environments.
Timeouts are typically set in the resource block using a timeouts argument. Terraform allows three main timeout attributes:
create— maximum duration to wait for resource creation.update— maximum duration to wait for updates or modifications.delete— maximum duration to wait for resource deletion.
For example:
resource "aws_instance" "example" {
# ...
timeouts {
create = "30m"
delete = "15m"
}
}If the operation does not finish within the specified duration, Terraform aborts the action and marks the resource as errored.
Note: Timeouts are provider- and resource-specific — they are not a universal Terraform core feature. They are defined by each resource implementation within its provider. Always check the resource’s page in the Terraform Registry to confirm which timeout attributes are available.
Terraform timeouts are particularly helpful for managing long-running operations or resources that can get stuck during provisioning. Here are the common scenarios:
- Resources with long provisioning times – If you know these resources (e.g., AWS RDS instances) typically take longer than the default timeout, configure a longer timeout to prevent Terraform from failing prematurely.
- To avoid hanging or infinite waits – If you notice that Terraform sometimes hangs indefinitely (due to API or network issues), defining explicit timeouts can help your runs fail faster and cleanly recover later.
- For resources with unpredictable behavior – Some APIs may not consistently report completion status. You can adjust timeouts to match realistic expectations based on experience or documentation.
- Custom providers or modules – When using custom or community providers, you might need to override defaults that aren’t suitable for your environment.
Only set custom timeouts when needed, as many providers already have generous defaults (for example, some AWS resources use defaults up to 120 minutes).
Let’s take the example of an AWS EC2 instance. Suppose sometimes instance creation can take longer due to delayed infrastructure provisioning, so you want to customize the timeout values.
resource "aws_instance" "example" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
timeouts {
create = "10m"
update = "5m"
delete = "5m"
}
}In the example above, the timeouts block defines:
create = "10m"– Terraform will wait up to 10 minutes for the EC2 instance to be createdupdate = "5m"– If you modify the resource (e.g., change its instance type), Terraform will wait 5 minutes for the update to completedelete = "5m"– When destroying the resource, Terraform waits 5 minutes before giving up
If the operation exceeds the specified duration, Terraform throws an error and halts execution, marking the resource as failed. This prevents Terraform from hanging indefinitely in cases where an API call is stuck or slow.
Let’s say you are creating an AWS RDS PostgreSQL instance, which can sometimes take 15–30 minutes to provision, depending on its size, multi-AZ configuration, or maintenance settings. By default, Terraform may have a shorter timeout that fails before AWS finishes provisioning.
To handle this gracefully, you can define a custom timeout:
resource "aws_db_instance" "postgres_db" {
allocated_storage = 20
engine = "postgres"
instance_class = "db.t3.micro"
db_name = "exampledb"
username = "admin"
password = "secretpassword"
skip_final_snapshot = true
timeouts {
create = "40m"
delete = "20m"
}
}In this example:
create = "40m"– Allows Terraform to wait longer for the DB instance creationdelete = "20m"– Helps when tearing down large or multi-AZ instances that may take a while to shut down
By using timeouts strategically, you make your Terraform runs more resilient, less prone to false failures, and better aligned with the cloud provider’s behavior. It’s an important reliability feature in production-grade Terraform setups.
Terraform is really powerful, but to achieve an end-to-end secure GitOps approach, you need to use a product that can run your Terraform workflows. Spacelift takes managing Terraform to the next level by giving you access to a powerful CI/CD workflow and unlocking features such as:
- Policies (based on Open Policy Agent)
- Multi-IaC workflows
- Self-service infrastructure
- Integrations with any third-party tools
If you want to learn more about Spacelift, create a free account today or book a demo with one of our engineers.
Note: New versions of Terraform are placed under the BUSL license, but everything created before version 1.5.x stays open-source. OpenTofu is an open-source version of Terraform that expands on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6.
Manage Terraform better with Spacelift
Build more complex workflows based on Terraform using policy as code, programmatic configuration, context sharing, drift detection, resource visualization, and many more.
