Problem
When a user runs azd provision while a previous deployment is still active on the same resource group, ARM returns a DeploymentActive error. The user waits an average of 5.3 minutes before seeing this failure, with no indication that another deployment was already running.
Telemetry Data
From Kusto analysis of service.arm.deployment.failed (source: ddazureclients.kusto.windows.net / DevCli / RawEventsAppRequests, March 1-23, 2026):
DeploymentActive inner error code: 199 failures in March (23 days)- Projected monthly volume: ~270 failures/month
- Average wait before failure: 5.3 minutes (median 2.4 min, P90 12.2 min)
- 78% of these come from
provision, 19% from up
DeploymentActive is one of several Conflict errors (the top ARM error category at 67.2% of all ARM deployment failures / 7,478 in March). Unlike most Conflict errors, DeploymentActive has a clear detection and recovery path.
Proposed Fix
Before starting a deployment, check for active deployments on the target resource group:
GET /subscriptions/{sub}/resourcegroups/{rg}/providers/Microsoft.Resources/deployments?$filter=provisioningState eq 'Running'&api-version=2021-04-01
If an active deployment is found:
- Warn the user: "A deployment is already in progress on this resource group."
- In interactive mode: prompt to wait or cancel
- In
--no-prompt mode (and for AI agents): wait for the active deployment to complete, then proceed
This could be implemented as a preflight check in the validation framework (@vhvb1989 is building in #7179, #7112-#7120), or as a guard at the start of the bicep provider's Deploy method.
Context
This is part of a broader ARM failure analysis. The full service.arm.deployment.failed breakdown for March 2026:
| ARM Error Code (frame 0) |
Count |
Share |
| Conflict |
7,478 |
67.2% |
| BadRequest |
1,602 |
14.4% |
| Conflict,Conflict |
636 |
5.7% |
| NotFound |
160 |
1.4% |
| InvalidTemplateDeployment |
123 |
1.1% |
| InternalServerError |
114 |
1.0% |
Related issues: #7115 (never abort on validation errors), #7119 (location validation)
Problem
When a user runs
azd provisionwhile a previous deployment is still active on the same resource group, ARM returns aDeploymentActiveerror. The user waits an average of 5.3 minutes before seeing this failure, with no indication that another deployment was already running.Telemetry Data
From Kusto analysis of
service.arm.deployment.failed(source:ddazureclients.kusto.windows.net/DevCli/RawEventsAppRequests, March 1-23, 2026):DeploymentActiveinner error code: 199 failures in March (23 days)provision, 19% fromupDeploymentActiveis one of severalConflicterrors (the top ARM error category at 67.2% of all ARM deployment failures / 7,478 in March). Unlike most Conflict errors,DeploymentActivehas a clear detection and recovery path.Proposed Fix
Before starting a deployment, check for active deployments on the target resource group:
If an active deployment is found:
--no-promptmode (and for AI agents): wait for the active deployment to complete, then proceedThis could be implemented as a preflight check in the validation framework (@vhvb1989 is building in #7179, #7112-#7120), or as a guard at the start of the bicep provider's
Deploymethod.Context
This is part of a broader ARM failure analysis. The full
service.arm.deployment.failedbreakdown for March 2026:Related issues: #7115 (never abort on validation errors), #7119 (location validation)