Notification Hub Deployment Stuck

Hi @Jonathan Brenchley ,

Thanks for reaching out in Microsoft Q&A forum,

Based on the behavior you've described, where the deployment remains stuck at "Get Namespace Resource" and previously deleted Notification Hub namespaces no longer appear in the Azure portal but still prevent recreation, one possible cause is that the namespace deletion did not complete successfully in the backend. In some cases, this can leave stale metadata associated with the namespace, causing subsequent deployments or attempts to recreate the same namespace to fail or remain in a provisioning loop.

To help isolate the issue, we recommend verifying whether the deleted namespace still exists at the Azure Resource Manager (ARM) level by using Azure CLI. Even if the namespace is no longer visible in the Azure portal, checking through CLI can help determine whether it is still present or stuck in a non-terminal provisioning state.

You can perform the following checks:

• List the Notification Hub namespaces in the resource group:

    az notification-hub namespace list --resource-group <resource-group-name> --output table
  

  Check the status of a specific namespace:

    az notification-hub namespace show --resource-group <resource-group-name> --name <namespace-name>
  

  You can also verify the resource directly through Azure Resource Manager:

    az resource show --resource-group <resource-group-name> --resource-type "Microsoft.NotificationHubs/namespaces" --name <namespace-name>
  

If the namespace is still returned by these commands, you can try deleting it again using Azure CLI:

az notification-hub namespace delete --resource-group <resource-group-name> --name <namespace-name>

Alternatively, you can attempt deletion through Azure Resource Manager:

az resource delete --resource-group <resource-group-name> --resource-type "Microsoft.NotificationHubs/namespaces" --name <namespace-name> 

If the deletion continues to fail or the deployment remains stuck, as a temporary workaround you may consider creating a new Notification Hub namespace with a different globally unique name. This can help unblock your deployment while the original namespace is being investigated.

If the issue persists after trying the above steps, please share the requested information via private message with us so we can investigate further:

For additional guidance, please refer to the official Microsoft documentation:

• az notification-hub | Microsoft Learn
• https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resources-cli

Update:

As discussed, I'm glad to know that you're now able to successfully create both the Notification Hubs namespace and the notification hub. This indicates that the original issue related to namespace creation has been resolved.

Based on the latest information you've provided, the current behavior is different from the original issue. The error "The remote name could not be resolved" when accessing the newly created namespace endpoint indicates a DNS name resolution issue, which is a separate concern.

To ensure this is handled by the appropriate team and to keep the discussions focused, I kindly request that you create a new Microsoft Q&A thread specifically for the DNS resolution issue

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

“Get Namespace Resource” is the control-plane read operation; by itself, it does not mean the deployment is still progressing. Check the ARM state rather than relying on the portal list.

Use the correct subscription and resource group:

az notification-hub namespace show -g <resource-group> -n <namespace>

If it returns the namespace, note its provisioningState and resource ID, then delete it explicitly:

az notification-hub namespace delete -g <resource-group> -n <namespace> --yes

Afterward, wait for ARM to report deletion before recreating anything:

az notification-hub namespace wait -g <resource-group> -n <namespace> --deleted

Also run the namespace name-availability check. Notification Hubs namespace names are service-wide names, so a namespace can disappear from the portal while its name is still reserved. If the GET returns not found but availability is still false, there is no client-side force-purge operation; the deletion is still propagating or the service retained a backend record.

Review the failed deployment’s operation details and the Activity Log for Microsoft.NotificationHubs/namespaces write and delete events, capturing the request and correlation IDs. A unique namespace name is a reasonable temporary workaround. If a new unique namespace also hangs, or the old name remains unavailable after the delete has completed, open a Notification Hubs support case with the subscription, region, namespace resource ID, timestamps, and correlation IDs so the service team can remove the orphaned backend state.