Share via

Azure SWA intermittent 404s with custom domains

Hunter Brelsford 0 Reputation points
2026-05-14T00:34:21.0833333+00:00

Driving me crazy. I have used powershell to configure state and setup for two SWA's and they are returning intermittent 404s across two subscriptions in the same tenant

  1. the custom domains I am using are the same every time i redeploy per SWA (aXX1.XXXXX.com on XXXX-XXX-wXXX2-01)
  2. the SWA resource names are the same (swXXXXXXwus2-01)
  3. the custom domain is not the same on the two SWA's (IE SWA1 has aXXXXXX.com and SWA2 has aXXXXXcom)
  4. SWA custom domain has no problems
  5. SWA custom domains verified.

What I have tried.

  1. delete the SWA and reset it up 24 hours later - fail
  2. delete az staticwebapp hostname delete --name .... to force remove the host name. wait 45 mins (even though it says 15 mins), set it back up in the portal manually after 45 mins - fail
  3. WAIT 48 hours, the intermittent 404s still there - fail
  4. tried opening support ticket but there is no option for it?
  5. bypass Cloudflare and go direct, still fails but ONLY ON THE CUSTOM DOMAIN - fail

My next steps are to delete the SWA's and start fresh with NEW SWA resource name AND NEW sub domains. I REALLY dont want to do this as its a huge lift and shift but it generally makes me think that ADF that backs SWA is really messed up.

edited pii

Azure Static Web Apps
Azure Static Web Apps

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

4 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Praneeth Maddali 9,680 Reputation points Microsoft External Staff Moderator
    2026-05-18T17:51:16.6066667+00:00

    Hi @Hunter Brelsford

    Thanks for the update — great to hear the issue resolved itself after about 72 hours.

    What you experienced is unfortunately common when custom domains are removed or rebound while the Static Web App is still present (or vice versa). Azure’s global edge platform needs time to fully clean up the old hostname bindings and propagate the new ones. In practice, this can take anywhere from a few hours to a couple of days, even though the portal often says 15–30 minutes.

    Recommended production-safe approach:

    Always follow this order when you need to recreate or migrate:

    1. Remove the custom domain from the Static Web App first (via portal or az staticwebapp hostname delete).
    2. Wait until the domain no longer appears in the Custom domains list (refresh and check after 30–60 mins).
    3. Then delete the SWA resource if needed.
    4. When setting up the new SWA, add the custom domain after the app is created and fully deployed.
    5. Allow 1–2 hours (sometimes longer) for the binding and certificate to become fully active.

    This sequence significantly reduces the “ghost binding” issues you ran into.

    Reference :

    https://learn.microsoft.com/en-us/azure/static-web-apps/custom-domain

    https://learn.microsoft.com/en-us/azure/static-web-apps/custom-domain#manage-custom-domains

    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 If you face this issue again, feel free to share the details in a private message so we can check the backend for you.

    Happy to help if you need any further assistance!

    Was this answer helpful?

    0 comments
  2. Hunter Brelsford 0 Reputation points
    2026-05-18T17:41:54.1933333+00:00

    The issue seemed to resolve itself after about 72 hours. I believe this was related to removal of the custom domain before removal of the SWA and adding it back again. An incredibly sketchy process if its in production.

    Was this answer helpful?

    0 comments
  3. Hunter Brelsford 0 Reputation points
    2026-05-14T00:45:32.85+00:00
    1. records are set in cloudflare with proxy so they can be scanned by WAF, the cname is set to the correct address provided by the SWA.
    2. verified active
    3. the default url has no problems as previously stated only custom domains, and i have already performed these troubleshooting steps as listed in my initial post.
    4. I was deleting my SWA before i set it up again, and later i was removing my custom domain before removing the SWA then readding. Same problem with both of these domains.
    5. 48 hours is a long time to wait but i will wait. But if this was production and i am deploying in the same region this is a ridiculous ask in todays day when general DNS is ~5 mins in a region and max of ~4 hours in the country.
    6. do i still do this if it validates successfully? if i remove and re-add the domain it will push back the 48 hour #5 more and i need production working
    7. azure portal wont let me open a ticket is there a number

    Was this answer helpful?

    0 comments

  4. AI answer

    2026-05-14T00:34:37.7766667+00:00

    Intermittent 404s on Azure Static Web Apps custom domains almost always point to one of three areas, all of which can be validated without renaming or recreating everything:

    1. Confirm DNS is stable and unambiguous
      • For each custom domain (for example, abc1.hello.com, abc2.hello.com), ensure there is only one of the following:
        • A CNAME pointing to the SWA default hostname (for example, *.azurestaticapps.net), or
        • An A record (less common for SWA) pointing to the correct IP.
      • Never configure both an A record and a CNAME for the same hostname; this can cause intermittent resolution and 404s.
      • Use global DNS tools (like WhatsMyDNS or DNS Checker) to verify that the records are consistent worldwide and that there are no stale or conflicting records. Intermittent behavior is often due to some resolvers still seeing old or conflicting DNS entries.
    2. Verify the hostname binding and status in the SWA resource
      • In the Azure portal for each Static Web App, go to Custom domains and confirm:
        • Each custom domain is listed once.
        • The status is Active/Validated (no pending validation or error state).
      • If the domain was added using an A record, ensure the required TXT record is also present and correct. Missing TXT verification for an A-record mapping can cause Azure to not consistently route the hostname, resulting in 404s.
    3. Check for the classic “Azure 404 – Web app not found” pattern
      • When the 404 appears, test both:
        • The SWA default hostname (for example, swa-abc-wus2-01.azurestaticapps.net).
        • The custom domain (for example, https://abc1.hello.com).
      • If the default hostname always works but the custom domain intermittently returns 404, this matches the documented case where Azure can’t consistently associate the hostname with the app because of DNS or binding issues:
        • The domain might not be fully or correctly added to the app.
        • DNS might be pointing correctly some of the time but not all of the time.
      • The guidance in this case is to:
        1. Re-validate the DNS records (CNAME vs A+TXT) and remove any conflicting entries.
        2. In the portal, remove the custom domain from the SWA, wait for it to disappear from the list, then re-add it and wait for validation to show as successful.
    4. Avoid conflicting use of the same domain on other Azure resources
      • Ensure the same hostname (for example, abc1.hello.com) is not also bound to any other Azure resource (another SWA, App Service, Front Door, etc.). A domain can be linked to only one app service-type resource at a time. If it was previously used elsewhere, remove it there first.
    5. Allow for propagation and cache clearing, but don’t rely on time alone
      • DNS changes can take up to 48 hours to propagate globally, but if intermittent 404s persist beyond that, the issue is usually misconfiguration rather than propagation.
      • Clear local DNS cache (ipconfig /flushdns on Windows) and browser cache when testing to avoid cached old IPs.
    6. If validation is stuck or inconsistent
      • There is a known pattern where custom domain validation can get stuck or behave oddly. A workaround that has helped in similar cases:
        1. Delete the CNAME for www (or the subdomain) at the DNS provider.
        2. Add the asuid.<subdomain> TXT record manually and wait for it to be visible globally.
        3. Let Azure validate the domain.
        4. Then delete the TXT and re-add the CNAME.
      • This can “unstick” validation and ensure Azure has a clean, verified mapping.
    7. When to recreate vs. when to escalate
      • Renaming SWA resources and domains is a heavy operation and usually not required if:
        • DNS is clean (no conflicting A/CNAME records).
        • The custom domains show as active/validated on the SWA.
        • The default SWA hostname is always stable.
      • If all of the above checks out and intermittent 404s still occur only on the custom domains, the next step is to open an Azure support case and provide:
        • Exact timestamps and sample URLs that returned 404.
        • Confirmation of DNS records and screenshots from the SWA Custom domains blade.

    Applying the above checks should allow resolution without changing SWA names or subdomains, unless a hidden conflicting binding or DNS record is discovered.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

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.