Intermittent 404s on both custom domains; default hostname unaffected

Question

Intermittent 404s on both custom domains; default hostname unaffected

Graeme Hedges 20

Static Web App: << >> (Free plan), resource group <<<>>>, West US 2 Default hostname: << >> Custom domains: << >> (apex, validated via << >>, ALIAS record at Porkbun) and www.brokk.gg (CNAME delegation) Both custom domains report status "Ready" with errorMessage null, and both have certificates issued (expiry 2027-02-08).

SYMPTOM

Both custom domains intermittently return 404 on valid routes that exist as real files. The default hostname, sampled in parallel, does not. Same app, same second, same route - the only variable is the Host header.

MEASUREMENT

HEAD requests to https://<host>/ at 8-second intervals, 41 samples per run:

~1 hour after binding: 6 failures / 82 requests (~7%)

~2.5 hours after binding: 13 failures / 82 requests (~16%)

after deleting preview environment: 13 / 82 (~16%)

The rate is not decaying - it roughly doubled between the first and second run and has held steady since. Failures cluster in time and sometimes hit both custom hostnames within the same sample. In an earlier run that also polled the default hostname alongside the two custom domains, the default hostname returned 200 on all 20 samples while the custom domains were failing in the same seconds.

RULED OUT

DNS. The resolved address (two addresses appear, alternating) shows no correlation with outcome. The apex sat on a single unchanging address for 41 consecutive samples and still failed 9 times within them.
Application routing. Astro static output, multi-page, no SPA router. Every tested route exists as a real file. The default hostname serves the identical content with no failures.
Preview environments. The app had one preview environment from an open PR. I deleted it and re-measured; the failure rate was unchanged at 16%.
Duplicate or competing resources. One Static Web App in the subscription. No App Service or other resource holds either hostname.
Orphaned bindings from a deleted resource. Confirmed clean - see history below.

HISTORY

This resource replaced an earlier Static Web App, << >> (<< >>), in the same resource group. Both custom domains were bound to that earlier resource on 06 Aug 23:11-23:22 UTC and cleanly deleted from it on 07 Aug 00:53-00:54 UTC. The resource itself was not deleted until 07 Aug 07:05 UTC, six hours later, so no binding was attached at deletion. The domains were then bound to the current resource. The activity log shows repeated write/delete cycles on both domains across 07-08 Aug while I was troubleshooting.

REQUEST

With every client-side cause I can test now eliminated, could someone inspect the backend for stale or inconsistent host-to-content-slot mappings for brokk.gg and www.brokk.gg? Happy to supply subscription and resource IDs privately. I'd also welcome a view on whether moving off the Free plan would trigger a re-provision that clears this, rather than my guessing. Full timestamped loop output available on request.

0 comments

Answer accepted by question author

Golla Venkata Pavani 7,530 Microsoft External Staff Moderator

Hi @Graeme Hedges

Thank you for the detailed update and for sharing the full timeline and troubleshooting results.

I’m glad to hear the issue has now resolved without any further configuration changes. Based on the behavior you observed, this does point strongly toward a backend/edge propagation or host-to-content mapping issue affecting the custom domains, rather than an application, DNS, or routing problem.

Your comparison with the default *.azurestaticapps.net hostname was particularly useful. Since the default hostname consistently returned 200 while the custom domains intermittently returned 404 for the same routes and at the same time, this effectively isolated the issue to the custom-domain path.

The fact that the issue resolved approximately 36–48 hours after the previous Static Web App was deleted, with no additional changes during the final ~14 hours, is also consistent with delayed propagation/cleanup of the custom-domain configuration across the Static Web Apps edge infrastructure.

We appreciate the additional observations regarding repeated rebinding. While we cannot confirm the exact internal mechanism without backend investigation, your experience suggests that repeated remove/re-add operations may have extended the time required for the configuration to fully converge.

For future cases with similar symptoms, the following approach would be useful:

Compare the custom hostname against the default *.azurestaticapps.net hostname using the same route and timestamps.
If the default hostname remains consistently healthy while custom domains intermittently return 404, focus investigation on the custom-domain/edge layer rather than the application or DNS.
Avoid repeatedly removing and re-adding the domains unless specifically advised, as propagation may take significantly longer than the portal's nominal timeframe.
Allow sufficient time for backend/edge propagation, particularly when the domains were previously associated with another Static Web App that has since been deleted.

We will also retain your timeline and observations as useful diagnostic information for similar cases.

Thank you again for the thorough investigation and for documenting the resolution. Your findings should be very helpful in distinguishing this type of issue from an application or DNS problem.

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

Please "accept" if the information helped you. This will help us and others in the community as well.

0 comments

1 additional answer

Your answer

Answer 1

Update: resolved on its own, with no further changes from my side.

Timeline (UTC):

07 Aug 00:53 Custom domains cleanly removed from the previous Static Web App.

07 Aug 07:05 Previous Static Web App deleted.

08 Aug 17:04 Final binding write on the current app. Both domains Ready, certificates issued.

08 Aug 19:30 Still failing: 13 failures / 82 requests (~16%).

09 Aug 07:06 Clean: 0 failures / 140 requests across both hostnames.

That's roughly 36-48 hours after the previous Static Web App was deleted, and about 14 hours after I stopped making changes. I made no configuration changes in between - no rebinding, no DNS edits, nothing.

For anyone landing here with the same symptom (both custom domains intermittently 404 while the *.azurestaticapps.net hostname is consistently fine):

Poll the default hostname in the same loop, in the same seconds, as the custom domains. If it never fails while they do, your app and your DNS are not the problem and you can stop testing them. This was the single most useful thing I did.
Resist rebinding. Every remove/re-add appears to restart edge propagation. I rebound the domains more than a dozen times across two days trying to fix it, which almost certainly prolonged the outage rather than shortening it.
Budget 24-72 hours after the last change, not the 15-30 minutes the portal suggests - especially if the domain was previously bound to a Static Web App that has since been deleted.

Thanks to the earlier threads here that reported their own resolution timings. That's what stopped me from tearing the whole thing down and rebuilding it.