Custom domain returns intermittent 404 after Static Web App recreation with the same domain name

[aarmandomichel1]

Describe the bug

After two Static Web Apps were destroyed and recreated with the same custom domain names, requests to those custom domains return HTTP 404 for roughly half of all requests, while the auto-generated *.azurestaticapps.net hostnames serve correctly 100% of the time.

The custom domains report status: Ready in the control plane and DNS resolves correctly, so this looks like stale or partially-applied hostname mappings on the edge fleet rather than a configuration problem on our side.

Environment

• Region: West Europe
• Two apps in the same resource group, Free tier, each with one custom domain:
  • swa-A → lemon-hill-030e51403.7.azurestaticapps.net → custom domain crm.bricktech.es
  • swa-B → ashy-sea-037a18303.7.azurestaticapps.net → custom domain portal.bricktech.es
• Both custom domains are CNAMEs proxied through Cloudflare; validation via dns-txt-token.
• Subscription ID available on request (omitted here since this issue is public).

Timeline

Time (UTC, 2026-08-01)	Event
09:20	Both Static Web Apps accidentally deleted (Terraform run against the wrong state)
~11:00	Both apps recreated with new auto-generated hostnames; custom domains re-added
11:04	crm.bricktech.es reaches Ready on the recreated app
~12:00	Intermittent 404s observed on both custom domains
20:08	crm.bricktech.es deleted and re-registered, hoping to clear the state; validation completes, Ready again
22:10	Still ~50% HTTP 404 on crm.bricktech.es; portal.bricktech.es (never re-registered) fluctuates between ~65% and 100% success

To Reproduce

for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code} " "https://crm.bricktech.es/?cachebust=$RANDOM"
done
# → e.g. 404 200 404 200 200 200 404 200 404 200 200 404 200 200 404 200 200 200 404 200

The auto-generated hostname, by contrast, is consistently healthy:

for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code} " "https://lemon-hill-030e51403.7.azurestaticapps.net/?cachebust=$RANDOM"
done
# → 200 200 200 200 200 ... (20/20)

Expected behavior

Once a custom domain reports Ready, all edge nodes should serve it consistently.

Additional context

1. The mixed responses come from a single IP. The app resolves through Traffic Manager to one address, and that same address alternates 404/200 across requests — so the inconsistency is between backend instances behind it, not between DNS answers.

2. Transient canonical-redirect inconsistency. For a period, the auto-generated hostname of swa-A responded 301 redirecting to the custom domain on some nodes, while other nodes served content for that same hostname normally. This made a common workaround (reverse-proxying to the auto-generated hostname) produce a redirect loop for end users. The 301s later stopped appearing without any change on our side. Meanwhile swa-B's auto-generated hostname never redirected, despite having an equivalent single-custom-domain configuration.

3. Re-registering the custom domain did not help. Deleting and re-adding crm.bricktech.es completed validation normally but did not resolve the intermittent 404s.

Questions

1. Is there a known issue when a Static Web App is deleted and a new one is created that re-uses the same custom domain name — can stale mappings from the deleted app persist on part of the edge fleet?
2. Is there a supported way to force a refresh of custom-domain mappings across the fleet?
3. What is the expected propagation window after a custom domain reaches Ready? The documentation does not state one, which makes it hard to tell "still propagating" apart from "stuck".
4. Is there a recommended procedure when recreating a Static Web App that must keep the same custom domain (for example, a required waiting period before re-adding it)?

We currently mitigate by routing traffic through a Cloudflare Worker that addresses the origin by its auto-generated hostname, but that is a workaround and it conflicts with the canonical redirect described in point 2.

[JakeHarveyy]

Seeing the same fleet-state behaviour from a different tenant and region — filed as #1783 (East Asia, Standard, custom domain also CNAME'd through Cloudflare). Different symptom, but your point 1 is the finding I'd most want a maintainer to look at, because we measured the same asymmetry independently.

Auto-generated hostname healthy, custom domain split. Measured today, interleaved, unique query string per request so no cache can return a stored copy:

Hostname	current build	stale build
<app>.7.azurestaticapps.net	40/40	0
our custom domain	28/35	7/35 (20%)

Same file, same minutes. That matches your 20/20 on the auto-generated hostname against ~50% 404 on crm.bricktech.es.

Cloudflare is not doing it on our side — cf-cache-status: DYNAMIC on every probe, and the stale response is a genuinely different origin file rather than a cached copy:

stale:   last-modified: Mon, 03 Aug 2026 18:15:11 GMT   etag: W/"26677130"
current: last-modified: Mon, 03 Aug 2026 18:52:18 GMT   etag: W/"53232099"

Two builds 37 minutes apart, both live, selected per request.

Where ours differs: you get 404s, we get two different artifact sets both returning 200 — and in an earlier sample on 30 July the auto-generated hostname was splitting too, which it isn't now. So yours may be a hostname mapping pointing at a deleted app while ours is two artifact sets of one live app. Same class of stale fleet state, not proven the same bug.

Shared variables worth Microsoft ruling in or out:

1. Custom-domain name reuse across resources. You recreated apps reusing the same custom domain names. We moved hub.<redacted> off one Static Web App onto a new one in a different region on 28 July — different mechanism, same outcome of a hostname previously mapped elsewhere. MS Q&A 5910175 documents name reuse leaving ghost environment references that split traffic. Your point 3 — re-registering the domain did not clear it — matches: nothing customer-accessible refreshes that mapping.
2. Cloudflare proxying the CNAME on both sides. Probably incidental, but neither of us has been asked, and the split follows the custom domain rather than the origin in both reports.

Your question 2 is the one that matters and it has no published answer: is there a supported way to force a refresh of custom-domain mappings across the fleet? The only corrective action with a track record is Microsoft refreshing the backend instances server-side (MS Q&A 5618783, December 2025 — "The backend instance hosting that environment was refreshed and brought back into a healthy state"). There is no customer equivalent.

Related and still running: #1786 (3 August) has production deploys failing at content distribution while the same artifact reaches a preview environment in 16 seconds. #1773, #1774, #1777, #1779, #1780, #1781, #1782 cover 21–29 July. The Azure status history shows nothing for Static Web Apps across that window. The 2023 precedent, #1281, was confirmed by Microsoft privately and also never appeared on the status page.