Azure Static Web App : Logic behind default domain name partition id

Jean-Didier Totow Tom-Ata 20 Reputation points
2026-09-09T11:35:56.79+00:00

Dear all,

I’m looking for clarification regarding Azure Static Web Apps hostname partitioning and Private Endpoint DNS behavior.

We noticed that Static Web Apps can receive default hostnames such as:

textCopy
myapp.azurestaticapps.net

or

textCopy
myapp.3.azurestaticapps.net

From the Private Endpoint documentation , it appears that the numeric segment (3 in this example) represents a partition/scale unit/stamp identifier, and that the corresponding Private DNS zone must match this value, for example:

textCopy
privatelink.3.azurestaticapps.net

We would like to better understand the underlying platform behavior because this has architectural implications for automation and DNS governance in enterprise environments.

  1. What exactly does the partition ID / stamp represent in Azure Static Web Apps?
  2. When does the default domain name contain a partition id ?
  3. Is there a finite or published list of possible partition IDs?

Thanks in advance for your help

Azure Static Web Apps
Azure Static Web Apps

An Azure service that provides streamlined full-stack web app development.

0 comments
Answer accepted by question author
Divyesh Govaerdhanan 11,890 Reputation points MVP Volunteer Moderator
2026-09-14T23:37:22.1266667+00:00

Hi Jean-Didier Totow Tom-Ata,

Welcome to Microsoft Q&A,

The numeric segment is called a "slice" in Microsoft documentation. it's an internal partition or scale-unit identifier assigned to your resource, not a customer-configurable setting.

It identifies which internal scale unit (partition) your Static Web App instance is deployed into. Microsoft docs on custom domain migration confirm this directly: "Azure Static Web Apps only permit binding a unique domain to a single resource within a slice... a Static Web App site with the default URL of orange-pond-0a04b7203.2.azurestaticapps.net has been placed in slice number 2." This is why domain binding rules and your private endpoint's DNS zone name both key off it.

It's assigned automatically at resource creation and there's no way to predict or request one over the other. When a new static web app is created, the default domain suffix might be different from the default domain suffix(es) of previous static web apps. So you can get myapp.azurestaticapps.net (no partition segment) or myapp.3.azurestaticapps.net (with one), and it can differ between two apps created back to back in the same subscription and region.

There isn't one. Microsoft doesn't document a finite or enumerable set of partition IDs, and treating this as an internal implementation detail rather than a stable enum is the safer assumption for governance purposes.

For your automation and DNS governance case, don't hardcode or pre-provision based on assumed partition values. Both docs point to the same pattern: read the DefaultHostname property of the deployed resource (via ARM/Bicep output, az staticwebapp show --query defaultHostname, or the portal) after creation, then derive your private DNS zone name (privatelink.<PARTITION_ID>.azurestaticapps.net) from that value programmatically.

Please Upvote and accept the answer if it helps!!

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.