🚨 Azure Error Guide: 'Conflict' Another Operation Is Already in Progress

Exact Error Message

When two operations collide on the same Azure resource, Azure Resource Manager (ARM) rejects the second one with a Conflict status. The message usually looks like this:

(Conflict) Another operation on this or dependent resource is in progress.
To retrieve status of the operation use uri:
https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Network/locations/eastus/operations/3f9b2c1a-7e54-4d2b-9a10-2c8f1d6e4b77?api-version=2024-05-01.
Code: Conflict
Message: Another operation on this or dependent resource is in progress.

You will also see closely related variants depending on the resource provider and tooling:

Code: AnotherOperationInProgress
Message: The resource '/subscriptions/.../resourceGroups/rg-prod/providers/
Microsoft.Compute/virtualMachineScaleSets/vmss-api' is currently being updated.

ERROR: Deployment failed. Correlation ID: 1a2b3c4d-...
A previous deployment is in progress. Wait for it to complete and retry.

Pipelines that run az deployment group create or Terraform against an active deployment commonly surface a concurrent ARM deployment conflict with a DeploymentActive or Conflict code. All of these describe the same underlying situation: an in-progress operation is holding the resource.

What the Error Means

Azure Resource Manager serializes write operations on a single resource. Each resource has a provisioningState (for example Succeeded, Updating, Creating, Deleting, or Failed). While a resource is in a non-terminal state such as Updating or Creating, ARM treats it as locked for further mutations. Any second PUT, PATCH, or DELETE against that resource (or a resource it depends on) is rejected with Conflict / AnotherOperationInProgress rather than queued.

This is a safety mechanism. ARM cannot reliably reconcile two simultaneous mutations of the same desired state, so it refuses the later request and points you at the in-flight operation’s status URI. The error is almost always transient: once the first operation reaches a terminal state, the resource accepts new operations again.

Common Causes

• Concurrent pipelines or deployments touching the same resource. Two CI/CD runs (or a release and a hotfix) deploy to the same resource group or resource at the same time.
• A previous deployment is still running. ARM deployments at the resource-group scope are themselves serialized for the same deployment name; a re-trigger before the prior run finishes returns DeploymentActive.
• A stuck or long-running async operation. VM scale set rolling upgrades, large disk operations, AKS node pool updates, or App Gateway changes can run for many minutes, blocking everything that depends on them.
• Serialized network and scale set operations. Microsoft.Network (NSGs, route tables, subnets, Application Gateway) and Microsoft.Compute scale sets serialize updates aggressively, so parallel edits collide.
• Retry storms. Aggressive client retries fire new operations while the original is still in flight, multiplying conflicts instead of resolving them.
• A resource stuck in Updating or Deleting provisioningState. A genuinely hung operation leaves the resource locked until it times out or you intervene.

How to Reproduce the Error

The simplest reproduction is to launch the same resource-group deployment twice without waiting for the first to finish.

# Terminal 1: start a deployment (long-running template)
az deployment group create \
  --resource-group rg-prod \
  --template-file main.bicep \
  --name app-rollout \
  --no-wait

# Terminal 2: immediately fire a second operation at the same resource
az network vnet subnet update \
  --resource-group rg-prod \
  --vnet-name vnet-prod \
  --name subnet-app \
  --network-security-group nsg-app

The second command returns (Conflict) Another operation on this or dependent resource is in progress. Parallel pipeline stages that both target rg-prod, or two engineers running terraform apply against the same state, produce the same result.

Diagnostic Commands

All of the commands below are read-only. They tell you what is running and what state the resource is in, without mutating anything.

# List recent deployments in the resource group and their states
az deployment group list \
  --resource-group rg-prod \
  --query "[].{name:name, state:properties.provisioningState, ts:properties.timestamp}" \
  --output table

# Show a specific deployment's provisioning state
az deployment group show \
  --resource-group rg-prod \
  --name app-rollout \
  --query "properties.provisioningState" --output tsv

# Check the provisioningState of the resource itself
az resource show \
  --ids "/subscriptions/<sub>/resourceGroups/rg-prod/providers/Microsoft.Compute/virtualMachineScaleSets/vmss-api" \
  --query "properties.provisioningState" --output tsv

# List the individual operations inside the deployment
az deployment operation group list \
  --resource-group rg-prod \
  --name app-rollout \
  --query "[].{op:properties.provisioningOperation, state:properties.provisioningState, resource:properties.targetResource.resourceName}" \
  --output table

# Poll the operation status URI from the error message directly
az rest --method get \
  --url "https://management.azure.com/subscriptions/<sub>/providers/Microsoft.Network/locations/eastus/operations/3f9b2c1a-7e54-4d2b-9a10-2c8f1d6e4b77?api-version=2024-05-01"

# Look at the activity log to see who/what started the in-flight operation
az monitor activity-log list \
  --resource-group rg-prod \
  --offset 1h \
  --query "[].{op:operationName.value, status:status.value, caller:caller, ts:eventTimestamp}" \
  --output table

Start with az deployment group list and az resource show. If the resource reports Updating, Creating, or Deleting, you have found your blocker. The operation status URI (az rest) returns {"status": "InProgress"} until the original operation completes.

Step-by-Step Resolution

1. Identify the in-flight operation. Run az deployment group list and az resource show --query properties.provisioningState. The resource in a non-terminal state is the one holding the lock. Use az monitor activity-log list to find which caller or pipeline started it.

2. Wait for it to finish. The conflict is transient. Poll the operation status URI with az rest (or az deployment group show) until provisioningState reaches Succeeded or Failed. Do not keep firing retries while it is InProgress — that creates a retry storm. Most operations clear within a few minutes; rolling upgrades can take longer.

3. Serialize your deployments. The root fix is to stop two operations from racing. Configure pipeline concurrency so only one run targets a given resource group at a time. In Azure DevOps use a deployment job with an environment and exclusive lock; in GitHub Actions use a concurrency group keyed to the resource group:

   concurrency:
     group: deploy-rg-prod
     cancel-in-progress: false

4. Model dependencies inside one deployment, not across many. Instead of separate parallel deployments that touch overlapping resources, put them in a single template and let ARM order them with dependsOn. Run az deployment group create --what-if first to preview changes and catch overlapping mutations before they execute.

5. Add retry with backoff that respects state. When a retry is justified, check provisioningState before retrying and use exponential backoff (for example 30s, 60s, 120s). Only retry once the resource is back in a terminal state — retrying against an Updating resource just reproduces the conflict.

6. Handle genuinely stuck resources. If a resource sits in Updating/Deleting far past its expected window, inspect the activity log for a failed sub-operation. A resource lock (az lock list) or a hung dependency can stall it. In rare cases you must wait for ARM’s internal timeout (often 1-2 hours) before the state resets to Failed, after which a fresh deployment can proceed.

For a deeper look at structuring resilient pipelines, see our Azure deployment troubleshooting guides.

Prevention and Best Practices

• Enforce single-writer deployments per resource group with pipeline concurrency controls or environment locks.
• Use unique, stable deployment names so re-runs detect an active deployment instead of silently overlapping.
• Prefer one template with dependsOn over multiple deployments mutating shared resources.
• Run what-if in PR validation to surface overlapping changes before merge.
• Implement idempotent, state-aware retries with exponential backoff and jitter; never retry blindly.
• Avoid editing shared infrastructure (VNets, NSGs, scale sets) from ad-hoc CLI commands while a pipeline is mid-deploy.
• Add resource locks deliberately and remember to remove them; a forgotten CanNotDelete lock can masquerade as a conflict.

Related Errors

• AnotherOperationInProgress — The same condition, surfaced by a specific resource provider rather than the generic deployment layer.
• OperationNotAllowed — A request is rejected because the resource’s current state or quota forbids it, sometimes overlapping with conflict scenarios.
• ConflictError — A broader ARM conflict code that also covers desired-state mismatches.
• ResourceUpdateConflict — Two updates to the same resource conflict on its ETag or current configuration.
• RetryableError — A transient failure ARM flags as safe to retry after backoff.
• DeploymentActive — A new deployment with the same name was submitted while the previous one is still running.

Frequently Asked Questions

Is the Conflict / AnotherOperationInProgress error safe to ignore and retry? Usually yes, but not immediately. It is transient and clears once the in-flight operation finishes. Wait until the resource’s provisioningState is Succeeded or Failed before retrying, and use exponential backoff. Retrying while the operation is still InProgress just reproduces the conflict.

How long should I wait before retrying? It depends on the operation. Quick updates clear in under a minute; VM scale set rolling upgrades, AKS node pool changes, and large disk operations can take 10+ minutes. Poll the operation status URI from the error message with az rest rather than guessing a fixed delay.

Why do my parallel pipeline runs keep colliding even on different resources? ARM serializes operations on dependent resources too, not just the exact resource you target. Editing a subnet while a VM that uses it is deploying, or two pipelines sharing a VNet/NSG, will conflict. Serialize anything that touches the same resource group or shared networking.

A resource has been stuck in Updating for over an hour. What now? Check the activity log for a failed sub-operation and look for resource locks with az lock list. If nothing is recoverable, ARM’s internal timeout will eventually move the resource to Failed, after which a fresh, corrected deployment can run. Open an Azure support case if a control-plane operation is genuinely hung.