🚨 Azure Error: 'ResourceGroupBeingDeleted: resource group is in deprovisioning state' — Cause, Fix, and Troubleshooting Guide

What this error means

Azure rejects any create or update against a resource group that is mid-deletion with ResourceGroupBeingDeleted. Once a group enters the Deleting (deprovisioning) provisioning state, ARM will not accept new operations into it until the delete completes. The literal error:

{
  "error": {
    "code": "ResourceGroupBeingDeleted",
    "message": "The resource group 'app-rg' is in deprovisioning state and cannot perform this operation. Please try again later or contact support if the issue persists."
  }
}

The two realistic situations: a delete is legitimately still running, or a delete has stalled and left the group wedged in Deleting.

What users report

• A deployment or az resource create fails with ResourceGroupBeingDeleted.
• az group show reports provisioningState: Deleting.
• A pipeline that tears down and recreates a group in quick succession fails on the recreate.
• The group appears to hang in Deleting for a long time because one resource inside it will not delete.

Tenant and app configuration causes

• Delete still in progress — the group is large or has slow-deleting resources (soft-deleted vaults, backup items, private endpoints), and the async delete has not finished.
• Tear-down/recreate race — automation deletes the group and immediately tries to recreate resources in it (or a same-named group) before deletion completes.
• Stuck delete — a resource with a delete lock, a dependency held elsewhere, or a provider issue blocks the delete, leaving the group in Deleting indefinitely.
• Someone deleted it out of band — a person or cleanup job started deleting the group while your pipeline was still using it.

Confirming tenant configuration

Confirm the provisioning state:

az group show --name app-rg --query "properties.provisioningState" -o tsv

If it reads Deleting, find the deletion activity in the activity log to see when it started and whether it is progressing:

az monitor activity-log list \
  --resource-group app-rg \
  --offset 6h \
  --query "[?operationName.value=='Microsoft.Resources/subscriptions/resourcegroups/delete'].{time:eventTimestamp, status:status.value, caller:caller}" \
  -o table

List what is still inside the group — a lingering resource points at what is blocking the delete:

az resource list --resource-group app-rg \
  --query "[].{name:name, type:type, state:provisioningState}" -o table

Check for locks that would stall a delete:

az lock list --resource-group app-rg -o table

Resolution

If the delete is simply still running, wait for it to complete and then recreate; poll rather than hammering:

until [ "$(az group exists --name app-rg)" = "false" ]; do
  echo "still deleting..."; sleep 30
done
az group create --name app-rg --location eastus

If a lock is blocking the delete, remove it (only if intended) so deletion can finish:

az lock delete --name do-not-delete --resource-group app-rg

If a single resource is stuck, delete it directly to unblock the group:

az resource delete --ids <stuck-resource-id>

Serialize tear-down and recreate in automation — never issue a create against a group that a prior step just asked ARM to delete. Wait for az group exists to return false first.

If it stays wedged for an unreasonable time with nothing obvious blocking it, open a support request — a provider-side stuck delete sometimes needs Microsoft to clear.

Avoiding tenant drift

• Deletes are asynchronous. az group delete returns before the work is done; the group can sit in Deleting for many minutes.
• Soft-delete resources slow things down. Key Vaults, Recovery Services vaults, and backup items with soft-delete/purge protection commonly stall a group delete.
• Same name, new group is still blocked. You cannot recreate a group of the same name until the old one is fully gone.
• Locks survive intent. A CanNotDelete lock will keep a group in Deleting limbo; audit locks before scheduling automated tear-downs.

Related tenant errors

• ResourceGroupNotFound — the state after deletion completes, or a wrong-subscription lookup.
• Conflict: another operation is in progress — a sibling concurrency error on individual resources.
• ScopeLocked — a management lock blocking writes/deletes on a scope.