Follow

Follow
Custom Timeouts in AzureRM

Custom Timeouts in AzureRM

Preventing Terraform timeouts when deploying to Azure

James Cook's photo
James Cook
·Jan 5, 2023·

3 min read

Play this article

Table of contents

  • What version of AzureRM is required
  • What Timeouts can you set
  • When to use a Custom Timeout
  • Risk of setting a Custom Timeout
  • How do you configure a Custom Timeout

What version of AzureRM is required

Microsoft announced in 2.0 of the AzureRM provider that custom timeouts are supported. But this announcement didn't mean that all resources supported it. Still today, there are resources yet to support custom timeouts.

To identify what version of the provider supports custom timeouts for a particular resource, or if it's supported at all, you need to refer to the Hashicorp Registry and locate the resource you want to configure a custom timeout. On the resource page, scroll to the bottom, where you should see the heading Timeouts. This would indicate if the latest version of AzureRM support it.

If you are using an older version of AzureRM, it's worth checking the version to see if it supports timeouts.

What Timeouts can you set

Not all resources have the same timeout functions. Typically you can get:

Create
Update
Read
Delete

To confirm which timeouts can be set, refer to the HashiCorp Registry documentation for the resource under the heading Timeouts.

You can set the timeouts to seconds, minutes, or hours. From the documentation, you can identify the defaults and override them by setting the value you want.

When to use a Custom Timeout

You should use a custom timeout when curtain resource deployments take longer than the default timeout period. Usually, you will identify this from a deployment that failed due to a timeout or from a previous deployment experience you had.

For example, I recently tried deploying a large data-related resource that takes hours to deploy, but the default timeout was set to one hour. This resulted in my deployment failing. For this, I decided to change the timeout period to four hours instead.

Risk of setting a Custom Timeout

There is a low risk when configuring a custom timeout. There could be an actual fault in the deployment that the provider has not picked up. For example, the four-hour timeout I used in my data resource deployment might be bugged but will not timeout until the set period. I could cancel the deployment, but this could corrupt the state file due to terminating Terraform in the middle of the deployment.

So when considering a long custom timeout, consider if it's needed and if you can wait for the maximum timeout period (do not set something silly like 100 hours).

How do you configure a Custom Timeout

It's pretty straightforward to configure a custom timeout in a resource block. You need to add the following:

  timeouts {
    create = "1h"
    delete = "15m"
  }

Below is an example I have used for Key Vault:

resource "azurerm_key_vault" "main" {
  name     = "main_key_vault"
  location = "UK South"
  resource_group_name         = azurerm_resource_group.main.name
  enabled_for_disk_encryption = true
  tenant_id                   = #######
  soft_delete_retention_days  = 7
  purge_protection_enabled    = true
  sku_name = "standard"

  timeouts {
    create = "10m"
    delete = "30m"
  }
}

Did you find this article valuable?

Support James Cook by becoming a sponsor. Any amount is appreciated!

See recent sponsors Learn more about Hashnode Sponsors
 
Share this