The Azure provider returns a 409 Conflict error with 'ServiceBusy' message when the service is temporarily busy or when concurrent operations conflict. This is typically a transient issue caused by service load, concurrent resource modifications, or firewall/proxy interference with retry logic.
A 409 Conflict error occurs when your Terraform request cannot be completed due to a conflict with the current state of Azure resources or when the Azure service is temporarily unavailable. The ServiceBusy variant specifically indicates that Azure's Resource Manager service is processing too many operations and cannot accept the request at this moment. This is distinct from permanent state conflicts—it's a temporary resource contention issue.
In most cases, the 409 ServiceBusy error is transient. Simply re-run the terraform apply command. If the error was temporary service load, the second attempt will succeed without any code changes.
terraform applyThis resolves the issue in the majority of cases.
If the error persists across multiple retries, add explicit dependencies between resources that may be conflicting. This forces Terraform to create resources sequentially rather than in parallel, reducing contention.
resource "azurerm_storage_account" "sa1" {
name = "storage1"
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
account_tier = "Standard"
account_replication_type = "LRS"
}
resource "azurerm_storage_account" "sa2" {
name = "storage2"
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
account_tier = "Standard"
account_replication_type = "LRS"
depends_on = [azurerm_storage_account.sa1]
}If errors persist after retries, work with your network administrator to verify that any firewall or proxy between your Terraform client and Azure is not interfering with HTTP retry logic.
Specifically, check that the HTTP RFC Retry-After response-header field is configured correctly. Ensure it includes appropriate status codes and that HTTP 202 (Accepted) responses are not being flagged as security threats or blocked.
You can enable debug logging in Terraform to see the actual HTTP responses:
TF_LOG=DEBUG terraform apply 2>&1 | grep -i "retry\|409\|202"If the error message mentions that a resource already exists (e.g., 'RoleAssignmentExists'), verify whether the resource was created outside of Terraform or in a previous failed run.
Import the existing resource into your Terraform state:
terraform import azurerm_resource_type.name /subscriptions/{sub-id}/resourceGroups/{rg-name}/providers/Microsoft.Provider/resourceType/{resource-name}Then update your Terraform configuration to match the imported resource.
If using the AzAPI provider (newer alternative to AzureRM), you can configure custom retry logic for specific error patterns:
terraform {
required_providers {
azapi = {
source = "Azure/azapi"
}
}
}
provider "azapi" {
retry_config {
error_message_regex = ["ServiceBusy", "429"]
interval_seconds = 10
max_interval_seconds = 180
}
}This will automatically retry requests matching these patterns with exponential backoff.
For large infrastructure deployments, split the terraform apply into multiple smaller operations targeting different resource groups or technologies. This reduces the load on Azure's service endpoints.
For example, instead of applying all resources at once:
# First wave: core infrastructure
terraform apply -target=azurerm_resource_group.main
# Second wave: storage
terraform apply -target=azurerm_storage_account.primary
# Third wave: compute
terraform apply -target=azurerm_virtual_machine.mainServiceBusy is classified as a transient error in the Azure SDK, meaning it should be automatically retried by the Terraform provider. However, the AzureRM provider's retry logic may not cover all scenarios, particularly when firewall or proxy systems intercept retry headers. Microsoft has confirmed that Retry-After behavior in response headers is by design. In rare cases, if a resource was created but Terraform state tracking failed (e.g., due to network interruption), the resource already exists in Azure but Terraform isn't aware, causing a 409 error on retry. Use 'terraform state' commands to manually inspect and correct state if needed. The newer AzAPI provider includes more granular retry configuration options and may handle this error more gracefully than AzureRM.
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