How to fix Provider responds with 409 Conflict and errors with ServiceBusy in Terraform

TerraformINTERMEDIATEMEDIUMUpdated Dec 30, 2025· 139 views

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.

Quick fix

Fixes Provider responds with 409 Conflict and errors with ServiceBusy

terraform apply
  1. Run terraform apply again
  2. Add explicit dependencies to serialize resource creation
  3. Verify firewall/proxy retry configuration
  4. Check for and import existing resources
terraform — error
terraform apply
Provider responds with 409 Conflict and errors with ServiceBusy

What this error means

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.

Typical symptoms

  • terraform apply fails mid-execution with '409 Conflict' response
  • Error message includes 'ServiceBusy' in the response body
  • Retry of terraform apply succeeds without code changes
  • Multiple concurrent resource operations intermittently fail
  • Errors occur only with certain resource combinations or deployment sizes

Common causes

  1. Azure service is temporarily overloaded and rejecting new operations
  2. Multiple Terraform resources targeting the same or related Azure resources are being created/modified concurrently, causing resource locks
  3. Firewall or proxy intercepting HTTP Retry-After headers, preventing proper exponential backoff
  4. Retry-After response header field configured incorrectly with HTTP 202 status type, flagged by security systems
  5. Role assignment or resource already exists but Terraform state is out of sync
  6. Azure backend temporarily enforcing exclusive access during resource initialization

How to fix "Provider responds with 409 Conflict and errors with ServiceBusy"

1Run terraform apply again

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.

bash
terraform apply

This resolves the issue in the majority of cases.

2Add explicit dependencies to serialize resource creation

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.

hcl
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]
}
3Verify firewall/proxy retry configuration

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:

bash
TF_LOG=DEBUG terraform apply 2>&1 | grep -i "retry\|409\|202"
4Check for and import existing resources

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:

bash
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.

5Enable provider-level retry configuration (AzAPI)

If using the AzAPI provider (newer alternative to AzureRM), you can configure custom retry logic for specific error patterns:

hcl
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.

6Split large deployments into smaller waves

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:

bash
# 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.main

Advanced notes

ServiceBusy 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.

Frequently asked questions

What does "Provider responds with 409 Conflict and errors with ServiceBusy" mean?
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.
How do I fix "Provider responds with 409 Conflict and errors with ServiceBusy"?
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.
What causes "Provider responds with 409 Conflict and errors with ServiceBusy"?
Azure service is temporarily overloaded and rejecting new operations Multiple Terraform resources targeting the same or related Azure resources are being created/modified concurrently, causing resource locks Firewall or proxy intercepting HTTP Retry-After headers, preventing proper exponential backoff
Is the "Provider responds with 409 Conflict and errors with ServiceBusy" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading