Azure Communication Services Email resource stuck in Deleting after AsyncOperationTimedOut

Hi Siddhant,

The AsyncOperationTimedOut on create is what left ecs-qualis40 where it is. ARM accepted the create, the Communication resource provider never returned a terminal result, and the resource is now parked in Deleting - a non-terminal provisioning state.

That state is the whole problem. ARM only accepts delete and update operations once a resource reaches a terminal state (Succeeded, Failed, Deleted). While it sits in Deleting, ARM blocks the request before it ever reaches the resource provider, and it enforces that identically through the Portal, Azure CLI, Azure PowerShell and direct REST calls. Your delete attempts are colliding with an operation ARM still considers in flight.

Two things worth setting straight up front:

There is no force-delete for this resource type. The full parameter list for az communication email delete is --acquire-policy-token, --change-reference, --email-service-name/--name/-n, --ids, --no-wait, --resource-group/-g, --subscription and --yes/-y. There is no --force, and -y only skips the confirmation prompt. You will find az resource delete --ids --force and Remove-AzResource -Force suggested on older threads for this same ACS symptom - those are generic ARM parameters and they do not bypass the non-terminal state check.

Purge APIs will not help either. They apply only to resources that were already deleted, not to one that never completed its lifecycle. And since you already hold Owner at subscription scope, no RBAC change will move this.

What is worth doing, in order:

1. Rule out a delete lock on the resource group. A CanNotDelete lock normally returns an explicit error rather than a hang, so this is unlikely to be your cause, but it takes ten seconds to eliminate.

az lock list --resource-group rg-qualis40-prod --output table

To verify: no locks of type CanNotDelete are listed. If one is, remove it and retry the delete once.

1. Check whether the original deployment is still marked Running, and cancel it if so.

az deployment group list --resource-group rg-qualis40-prod --query "[].{name:name,state:properties.provisioningState,timestamp:properties.timestamp}" --output table

az deployment group cancel --resource-group rg-qualis40-prod --name <DEPLOYMENT_NAME>

To be clear about what this is: cancelling a still-running deployment may release the in-flight operation and let the resource settle into a terminal state, after which delete becomes legal again. I have not seen that documented specifically for emailServices, so treat it as worth trying rather than a guaranteed fix. Re-run the list command and confirm nothing shows Running, then re-check the resource:

az communication email show --name ecs-qualis40 --resource-group rg-qualis40-prod --query provisioningState --output tsv

1. Pull the Activity Log correlation IDs for the failed create and the failed delete. The Operation ID you posted is the ARM async operation handle. The correlation ID is a different value, and it is the one the resource provider team needs to trace this end to end. Run this as a single line:

az monitor activity-log list --resource-group rg-qualis40-prod --start-time 2026-08-24T00:00:00Z --offset 0 --query "[?contains(resourceId,'ecs-qualis40')].{op:operationName.value,status:status.value,corr:correlationId,time:eventTimestamp}" --output table

To verify: you get at least one row for Microsoft.Communication/emailServices/write, and if the delete was ever accepted, one for .../delete. Note both correlation IDs and the exact UTC timestamps.

1. Unblock yourself in parallel. Resource names in Azure only need to be unique within the resource group for a given type, so the stuck resource should only be blocking reuse of the name ecs-qualis40 in rg-qualis40-prod - not creation of a new Email Communication Service. Create one under a different name and carry on with your domain setup:

az communication email create --name ecs-qualis40-v2 --resource-group rg-qualis40-prod --location global --data-location unitedstates

To verify:

az communication email show --name ecs-qualis40-v2 --resource-group rg-qualis40-prod --query provisioningState --output tsv

You want Succeeded. If this one also stalls in Accepted, say so - two consecutive stalls in the same subscription points at something broader than a one-off timeout, and that is a materially different investigation.

One thing I would not do: delete rg-qualis40-prod to force the issue. That cascade removes everything in the group, and given the -prod naming that is a real risk for you. If you want it purely as a diagnostic, do it on a throwaway group.

If it is still stuck after steps 1 and 2, this needs the Communication Services resource provider to correct the state on the backend, and there is no client-side path left. Post back with the two correlation IDs from step 3, the exact UTC times of your create and delete attempts, and the output of:

az resource show --ids /subscriptions/268b56ec-e1d6-4695-9ae8-aac1728b7ab8/resourceGroups/rg-qualis40-prod/providers/Microsoft.Communication/emailServices/ecs-qualis40

With those in hand I can get this routed to the right team. If the state flips to Failed on its own in the meantime, retry the delete at that point - Failed is terminal, so ARM will accept it.

Thanks