Static Web Apps custom domain stuck at RetrievingValidationToken, fails after 10 minutes — slice 7 only

Question

Static Web Apps custom domain stuck at RetrievingValidationToken, fails after 10 minutes — slice 7 only

Waseem Ansari, MD 20

Adding a custom domain to any Azure Static Web App on slice 7 fails. The domain enters

RetrievingValidationToken, never advances to Validating, and times out to Failed at

about 10 minutes with:

"An unknown error has occurred while adding your custom domain. Please try again later."

An identical add on a slice 1 app succeeds in under 4 minutes. This looks like the

validation-token issuing service on slice 7 is broken.

WHAT I OBSERVED

Same tenant, same registrar, same parent domain. DNS verified correct at the

authoritative nameservers before every attempt.

App on slice 1 (*.1.azurestaticapps.net)

  RetrievingValidationToken -> Validating -> Ready in 3m54s   SUCCESS

App on slice 7 (*.7.azurestaticapps.net)

  RetrievingValidationToken -> (never reaches Validating) -> Failed at 10m17s

The slice 7 app already has a different custom domain in Ready state, bound

successfully a few days earlier. It can no longer bind a NEW one. So this is not a

broken or misconfigured resource — it is the slice.

In total, 7 hostnames failed across 2 different Static Web Apps in 2 different resource

groups, all on slice 7, all with the same state transition and the same 10-minute timeout.

REGRESSION WINDOW

Last successful custom domain bind on slice 7: 2026-08-10 17:07 UTC.

First failure: 2026-08-12 14:26 UTC.

Something appears to have changed in that ~46 hour window.

ALREADY RULED OUT (tested, not assumed)

DNS correctness — verified at the authoritative nameservers, 1.1.1.1, and Google DoH
DNS propagation / waiting longer
Conflicting A/AAAA/TXT records
CAA — no CAA records exist on the parent domain, so issuance is unrestricted
DNSSEC — no DS/DNSKEY records
Validation method — using cname-delegation; EnterpriseGradeCdnStatus is Disabled
Entry method — portal, az CLI, and raw ARM PUT all fail identically
The resource itself — a healthy app with a live custom domain fails the same way
Tier — Free and Standard both fail
Region — see below

WHY I CANNOT USE THE DOCUMENTED WORKAROUND

The usual advice for a stuck custom domain binding is to recreate the Static Web App

until it lands on a different slice. I created 6 new Static Web Apps across 2 regions

(West US 2 and East US) on the Free tier. Every single one was allocated to slice 7.

New allocations appear to be pinned there, so recreating cannot escape the problem.

CORRELATION IDs (all ResourceOperationFailure, terminal provisioning state 'Failed')

bf05647b-6c01-4655-b297-83968f7a892d

b975eb4b-7cdf-4298-9ac1-16286ede0856

cea97715-e258-4b3c-aa04-f3ba36bebd59

40b9d0df-f00d-4c44-bca5-782ef86ee330

7b44cf72-ad76-4454-b5e1-665fc3780c56

QUESTIONS

Is there a known issue with validation-token issuance on slice 7?
Is there any way to influence which slice a new Static Web App is allocated to, given region and tier both had no effect?
Two custom domain entries are wedged in "Deleting" state. Delete via portal, az CLI, and raw ARM DELETE all return success but never reconcile. Is there any customer-side way to release these, or does it require backend intervention?

Happy to share resource IDs and the subscription privately if that helps.

Aditya N 3,890 Reputation points Microsoft External Staff Moderator

2026-08-14T16:35:40.76+00:00

Hello @Waseem Ansari, MD

Please retry the operation and let us know whether everything is working as expected.

If you’re still experiencing any issues, just reply with an update and any relevant details. We’ll be happy to continue assisting you and investigate further if needed.

We look forward to hearing back from you.
Aditya N 3,890 Reputation points Microsoft External Staff Moderator

2026-08-18T12:17:23.0333333+00:00

Hello @Waseem Ansari, MD

Please could you let us know if you were able to retry the operation.

Answer accepted by question author

0 additional answers

Your answer

Aditya N 3,890 Reputation points Microsoft External Staff Moderator

2026-08-14T16:35:40.76+00:00

Hello @Waseem Ansari, MD

Please retry the operation and let us know whether everything is working as expected.

If you’re still experiencing any issues, just reply with an update and any relevant details. We’ll be happy to continue assisting you and investigate further if needed.

We look forward to hearing back from you.
Aditya N 3,890 Reputation points Microsoft External Staff Moderator

2026-08-18T12:17:23.0333333+00:00

Hello @Waseem Ansari, MD

Please could you let us know if you were able to retry the operation.

Answer 1

Hi,

Please retry deleting your custom domain(s) via the portal. There was an issue (details below) last few days that has been mitigated.

In regards to adding custom domain, have you tried again today? I'm asking because there may be a separate issue that is blocking you from adding custom domain on slice 7.

Below is excerpt from Post Incident Review (PIR) DZXC-65Z:

What happened?

Between 14:30 UTC on 11 August 2026 and 15:50 UTC on 13 August 2026, a platform issue resulted in an impact to the Azure Static Web Apps service in multiple regions. Impacted customers may have experienced failures or delays when deleting or adding custom domains for Azure Static Web Apps resources hosted in the affected regions. The impact was limited to a subset of customers.

What went wrong, and why?

A platform issue caused an increase in processing backlog for operations responsible for managing custom domain configuration changes. As a result, requests to delete or add custom domains were delayed or failed for a subset of Azure Static Web Apps customers. The issue was mitigated after service processing queues recovered to normal operating levels and pending operations were cleared.

How did we respond?

14:30 UTC on 11 August 2026 – Customer impact began.

13:04 UTC on 12 August 2026 – The issue was identified through customer reports of failures and delays when deleting custom domains.

23:28 UTC on 12 August 2026 – We identified elevated service processing queues as a contributing factor and initiated mitigation activities.

15:50 UTC on 13 August 2026 – Service processing queues recovered to normal levels and the impact was mitigated. Customers were advised to retry previously failed operations.

What happens next?

This Mitigation Statement is the final communication for this incident. For details about which Azure incidents qualify for which Post Incident Reviews (PIRs), refer to https://aka.ms/AzurePIRs

The impact times above represent the full incident duration, so are not specific to any individual customer. Actual impact to service availability may vary between customers and resources – for guidance on implementing monitoring to understand granular impact: https://aka.ms/AzPIR/Monitoring

To stay informed about future Azure service issues, make sure that you configure and maintain Azure Service Health alerts – these can trigger emails, SMS, push notifications, webhooks, and more: https://aka.ms/ash-alerts

For broader guidance on preparing for cloud incidents, refer to https://aka.ms/incidentreadiness

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP