Static Web App (Standard) behind a Private Endpoint: custom domain intermittently returns the branded 404 page on existing assets, even against a single pinned PE IP

Question

Static Web App (Standard) behind a Private Endpoint: custom domain intermittently returns the branded 404 page on existing assets, even against a single pinned PE IP

Erik Micheel 20

Setup:
Azure Static Web App, Standard plan, West Europe.

publicNetworkAccess = Disabled. The app is reachable only via a Private Endpoint inside a VNet. Inbound user traffic enters through Zscaler ZPA App Connectors in that VNet.
PII
Custom domain: project.contoso.software (status Validated/Ready; public DNS at an external registrar resolves, certificate auto-renewal is healthy).
Private DNS zones in the VNet: privatelink.7.azurestaticapps.net (resolves the autogenerated host to the PE IP) and a zone for the custom domain (CNAME custom -> autogenerated host).
az staticwebapp environment list returns exactly one environment: default, status Ready. No staging/preview environments.

Problem:
Existing static assets intermittently return the Static Web Apps branded "404: Not Found" page when requested on the custom domain, while the autogenerated hostname served them stably (before I set the custom domain as the default domain, which now makes the autogenerated host return a 301 redirect).

Evidence (the part I can't explain) 50 sequential requests for one existing asset, forcing the connection to the single production private-endpoint IP (so DNS/round-robin is out of the picture), run on the in-VNet ZPA connector (no browser/proxy/CDN cache):

curl -skv --resolve project.contoso.software:443:10.20.0.5 -w "%{http_code} %{content_type} %{size_download}\n" https://project.contoso.software/assets/index-DRkdI0yH.js

Result: 38x 200 / 12x 404 (about 24%), binary outcome, never partial:

200 -> text/javascript, full file (about 198 KB)
404 -> text/html, about 2.4 KB, the SWA branded "We couldn't find that page"

The TLS certificate is identical on the 200 and the 404 responses (same custom-domain certificate, same SHA-256 fingerprint), confirmed in the browser certificate viewer. So the failing requests do reach a backend that holds the custom-domain certificate, but that backend returns the branded 404 for every path including /index.html, i.e. it behaves like a content slot with no deployed site.

What I've ruled out

Build / missing file: the same asset returns the full correct file 76% of the time; the 200 body is always complete.
staticwebapp.config.json / navigationFallback: a fallback would return index.html with HTTP 200; I get HTTP 404 plus the platform branded page.
TLS / custom-domain binding / certificate: identical custom certificate on both 200 and 404.
DNS / wrong (staging) IP: the connection is pinned to one IP and still flaps about 24%, so the inconsistency is behind that single PE IP.
Zscaler ZPA: reproduced directly on the connector against the raw PE IP; ZPA does not rewrite the Host header.
Stray environment: only the single default environment exists.
SWA "Availability and Performance" shows Site Errors = 0.

Question Behind a single private-endpoint IP, with only one default environment and a correctly served custom-domain certificate, why is the custom Host intermittently served by an empty content slot (branded 404), while the autogenerated hostname is stable? Is this a known behavior of the Static Web Apps content backend / scale-unit replicas behind a private endpoint, and how do I force the custom Host to consistently hit the populated production content? Any pointers before I escalate via a support case would be appreciated.

Aditya N 3,395 Reputation points Microsoft External Staff Moderator

2026-06-03T11:58:11.1833333+00:00

Hello @Erik Micheel

Thank you for reaching out Microsoft Q&A. Please could you provide name of static web app in private message.
Praneeth Maddali 11,350 Reputation points Microsoft External Staff Moderator

2026-06-04T01:32:36.3233333+00:00

Hi @Erik Micheel

Thank you for sharing the app details in the private chat.

As per my investigation from the backend, we found two Static Web Apps with the same name (XXXXXXX-dev) — one for production and one for staging/preview. This results in two private IPs behind the Private Endpoint, causing traffic to split between the populated production slot and an empty staging slot. This explains the intermittent branded 404 responses on your custom domain.

We have provided the recommended steps in the private chat to resolve this.

Reference:

https://learn.microsoft.com/en-us/azure/static-web-apps/private-endpoint

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

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

Answer accepted by question author

0 additional answers

Your answer

Aditya N 3,395 Reputation points Microsoft External Staff Moderator

2026-06-03T11:58:11.1833333+00:00

Hello @Erik Micheel

Thank you for reaching out Microsoft Q&A. Please could you provide name of static web app in private message.
Praneeth Maddali 11,350 Reputation points Microsoft External Staff Moderator

2026-06-04T01:32:36.3233333+00:00

Hi @Erik Micheel

Thank you for sharing the app details in the private chat.

As per my investigation from the backend, we found two Static Web Apps with the same name (XXXXXXX-dev) — one for production and one for staging/preview. This results in two private IPs behind the Private Endpoint, causing traffic to split between the populated production slot and an empty staging slot. This explains the intermittent branded 404 responses on your custom domain.

We have provided the recommended steps in the private chat to resolve this.

Reference:

https://learn.microsoft.com/en-us/azure/static-web-apps/private-endpoint

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

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

Answer 1

Hi @Erik Micheel

Thank you for the confirmation in our private chat. I'm glad to hear the issue is now resolved.

The issue was caused by residual backend metadata from a previously deleted Static Web App that had the same name

Azure retained "ghost" environment references (likely related to a previous staging/preview slot) on the backend. When using Private Endpoints, traffic was intermittently routed to an empty content slot, which returned the branded 404 page while still presenting the correct custom domain certificate.

This is a known edge-case behavior in Azure Static Web Apps when resources with identical names are recreated.

The issue self-resolved after Azure completed the backend cleanup of the old metadata. No manual changes were required on our end. The application is now consistently serving content from the correct Production environment.

Preventive Measures

Avoid reusing the exact same Static Web App name when recreating resources.

After deletion/recreation, wait a few hours and re-validate Private DNS + Private Endpoint configuration.

Monitor using pinned requests to the Private Endpoint IP after any major changes.

If the answer is helpful, Please do click "Accept the answer” and Yes, this can be beneficial to other community members.

If you have any other questions, let me know in the "comments" and I would be happy to help you