Azure Web App Naming Convention and Hostname Behavior.

Hi @Naik, Anilkumar

Greetings for the day, Thanks for reaching out to Q&A.

Thank you for the clear description of both attempts — that comparison is exactly what's needed to explain the difference.

Short answer: the two outcomes don't come from one rule. They come from two separate checks that run in sequence in the Create Web App wizard.

Root cause

The wizard evaluates app name availability first, and generates the default hostname second.

The Microsoft.Web/sites resource name must be globally unique across the entire public Azure cloud, and Web Apps, Function Apps, Logic Apps (Standard) and deployment slots all share that namespace.

• "webapp" is already owned somewhere in that cloud, so it failed the first check and the wizard never reached hostname generation — which is why no hash was offered.
• "webapptest" passed the first check, so the wizard proceeded and applied the secure unique default hostname.

The hash secures the hostname; it does not make a taken resource name usable.

To be transparent on confidence: the name-uniqueness behaviour is documented. The specific evaluation order inside the portal wizard is my assessment based on the output you observed, and is not spelled out in public documentation.

Steps to confirm and to control the behaviour

Step 1 — Verify the name status directly against the resource provider

az rest --method post --url "/providers/Microsoft.Web/checkNameAvailability?api-version=2022-03-01" --body "{\"name\":\"webapp\",\"type\":\"Microsoft.Web/sites\"}"

Why this matters: it separates the name check from the portal UI entirely. How to verify: a response of "nameAvailable": false, with a reason and message, confirms the name is taken or reserved — the same result the portal surfaced.

Step 2 — If you need the traditional predictable hostname, create the app outside the portal

For ARM, Bicep or REST, omit AutoGeneratedDomainNameLabelScope from the site properties. To opt in explicitly, set it to TenantReuse, SubscriptionReuse, ResourceGroupReuse or NoReuse:

"properties": {
  "serverFarmId": "<AppServicePlanResourceId>",
  "AutoGeneratedDomainNameLabelScope": "TenantReuse"
}

For the CLI:

az webapp create --name <AppName> --resource-group <ResourceGroup> --plan <AppServicePlan> --domain-name-scope TenantReuse

Why this matters: the portal applies the secure unique hostname automatically with TenantReuse and no longer exposes a toggle, so the API surface is the only place to control this. How to verify:

az webapp show --name <AppName> --resource-group <ResourceGroup> --query defaultHostName -o tsv

Expect <AppName>.azurewebsites.net when the property is omitted, or <AppName>-<Hash>.<Region>.azurewebsites.net when a scope is set.

Step 3 — Choose the hash scope deliberately if you deploy the same app name across environments

• TenantReuse — same hash for the same app name across every subscription in your Entra tenant
• SubscriptionReuse / ResourceGroupReuse — narrows that to the subscription or resource group
• NoReuse — a new hash on every creation

Why this matters: if you promote from a test subscription to production under the same tenant, TenantReuse keeps the hostname stable; NoReuse will change it on every redeployment. How to verify: create the same app name in two scopes and compare the defaultHostName values returned by the command in Step 2.

Two constraints to note

1. The feature can only be set at creation time. It cannot be applied to, or removed from, an existing app. The supported paths are Clone or Restore from backup into a new app — both available in the portal.
2. The region identifier in the hostname (for example eastus-01) may use a different number suffix for future deployments, so please don't take a hard dependency on that exact region-number pairing.

Documentation references

• Prevent subdomain takeovers in Azure App Service — see the sections "Secure unique default hostnames", "Hash scope options", "Deployment slots", "How to enable", "Migrating existing resources", and "How App Service prevents subdomain takeovers"
• Public Preview: Creating Web App with a unique default hostname
• Secure unique default hostnames GA on App Service Web Apps
• Secure unique default hostnames now GA for Functions and Logic Apps