Share via

Azure Static Web Apps 404 on valid Next.js route (/login)

Robert VAN DYKE 0 Reputation points
2026-05-01T17:59:13.03+00:00

I’m troubleshooting an Azure Static Web Apps deployment for a Next.js app and need help diagnosing why a valid route returns 404 in production.

Setup:

  • Static Web App: RXXX-AXX
  • Custom domain: rtXX-lXX.net
  • Repo: Hybrid_ProjectPlan_Package_plus_Automation_BI
  • App folder: rtuX-frontXXX
  • Workflow uses:
    • app_location: "rtXX-frontXXX"
    • output_location: ".next"
  • The deployment history shows successful deployments.
  • The Next.js production build contains the /login route.
  • The live site still returns 404 for:
  • This also happens on the default azurestaticapps.net hostname.
  • Incognito and fresh refreshes do not change the result.

What I have already verified:

  • The route exists in source at src/app/login/page.tsx.
  • next.config.ts does not use static export.
  • The Next build output contains /login:
    • .next/routes-manifest.json
    • .next/app-path-routes-manifest.json
    • .next/prerender-manifest.json
  • I tried staticwebapp.config.json in:
    • the app root
    • public/
  • I also tried setting config_file_location in the GitHub Actions workflow.
  • None of those changed the 404 behavior.

What I need help with:

  1. Determine why Azure Static Web Apps is returning 404 for /login even though the Next build artifact contains the route.
  2. Confirm whether this is a known Azure SWA + Next.js hybrid limitation or a deployment/serving issue.
  3. Tell me the correct supported way to make /login resolve in production for a hybrid Next.js app on SWA.
  4. If there is a route fallback, rewrite, or config requirement I missed, tell me exactly where it must live and how it must be deployed.
  5. If this is not supported the way I’ve deployed it, tell me the recommended production architecture or workaround.

Please look specifically for:

  • Azure Static Web Apps behavior with Next.js hybrid apps
  • direct route handling for App Router pages like /login
  • whether SWA is serving the deployed artifact correctly or if a rewrite/hosting limitation is causing the 404

I’d like the shortest path to a working production fix, not a broad list of possibilities.

Azure Static Web Apps
Azure Static Web Apps

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

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Golla Venkata Pavani 5,745 Reputation points Microsoft External Staff Moderator
    2026-05-04T14:02:55.4866667+00:00

    Hi @Robert VAN DYKE

    Thanks for the thorough follow-up and all the verification steps — it's clear you've done a solid job isolating this. Since the standard hybrid setup (standalone output + empty output_location) hasn't resolved the 404 on /login, let's focus on the most likely remaining causes for App Router server-rendered routes in the hybrid preview.

    Quick Diagnostic Checks:

    1. Test the health endpoint
      This is critical in hybrid mode: Visit https://rtuo-llc.net/.swa/health.html (and the default *.azurestaticapps.net version). It should return a successful page. If this returns 404 or fails, the managed backend isn't activating properly, causing all dynamic routes to 404.
    2. Review the detailed deployment logs in the Azure portal (Deployments > latest run) for any warnings about the backend, standalone folder, or route handling.
    3. Check Application Logs (portal > your SWA > Logs) right after hitting /login for backend errors.

    Make sure your setup exactly matches the official guidance:

    • next.config.ts: output: 'standalone'
    • Workflow:
      • app_location: "rtuo-frontend"
      • output_location: "" (empty)
      • api_location: "" (empty)
    • If you have middleware.ts, it must exclude the SWA health check: TypeScript 
        export const config = {
    matcher: ['/((?!.swa).*)'],
  };

    If the health check passes and logs look clean but /login still 404s, the hybrid preview may be hitting an edge case with your specific App Router setup (some dynamic features or middleware interactions are still maturing).
    Recommended Next Action:

    As a clean test, try recreating the Static Web App resource (or a new one) using the Next.js preset in the Azure portal wizard, then link your repo with the exact settings above. This often clears any stale routing state.

    If that doesn't resolve it, the shortest path to production stability right now is often switching to a full server hosting option like Azure App Service (Node.js) or Azure Container Apps, where Next.js runs without the hybrid preview limitations.

    Reference:
    https://learn.microsoft.com/en-us/azure/static-web-apps/deploy-nextjs-hybrid
    https://learn.microsoft.com/en-us/azure/static-web-apps/nextjs

    Kindly let us know if the above helps or 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.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-05-01T17:59:30.0766667+00:00

    Azure Static Web Apps returns 404 for a route in two main cases that match this scenario:

    1. The requested path does not map to a deployed file or a configured fallback route.
    2. Client-side routing is expected to handle the path, but no SWA fallback is configured to send that path to the SPA entry point.

    From the available information, the behavior matches case 2: SWA is treating /login as a server-side route that does not exist as a static asset and is not covered by a fallback rule, so it returns 404.

    For frameworks with client-side routing (including SPA-style Next.js apps), SWA requires a fallback route in staticwebapp.config.json so that unknown paths like /login are rewritten to the app’s main HTML (for example, /index.html). Without that, direct navigation to /login returns 404 even if the route exists in the client app.

    The documented fix is to configure a fallback route in staticwebapp.config.json and ensure that file is deployed in the correct location.

    Key points from the documentation:

    • Static Web Apps will 404 a client-side route if it does not correspond to a deployed file and no fallback is configured. The FAQ explicitly calls this out and points to fallback routes as the fix.
    • Fallback routes are defined in staticwebapp.config.json and can rewrite any non-file path to the SPA entry point.
    • The configuration file must be deployed with the app so that SWA can apply the routing rules.

    To make /login resolve in production:

    1. Add a fallback route in staticwebapp.config.json that rewrites all non-asset paths to the main HTML file (for example, /index.html). A typical pattern is:
    {
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": ["/images/*", "/css/*", "*.js", "*.css", "*.png", "*.jpg", "*.gif", "*.ico", "*.json"]
  }
}
    1. Place staticwebapp.config.json in the app’s output so SWA sees it at runtime. For Static Web Apps, the configuration file is read from the app’s deployed content (the same place SWA serves static files from). Ensure that when output_location: ".next" is deployed, the config file is present in the deployed artifact root that SWA serves.
    2. Redeploy and then request /login directly. With the fallback in place, SWA will rewrite /login to the configured HTML entry point and the Next.js client-side router can render the /login page.

    If /login is meant to be a static file (for example, a prerendered HTML file), then instead of relying on a fallback, ensure that the build produces a concrete file at a path SWA can serve (for example, /login/index.html) inside the output_location and that no route rule overrides it.

    If the app uses hybrid Next.js features that require server-side rendering or Node-based runtime behavior, Static Web Apps’ static hosting model may not be able to execute those server-side parts. In that case, the supported pattern is:

    • Host the static front-end (including client-side routes) on Static Web Apps with a fallback route configured.
    • Host any required server-side or API logic separately (for example, Azure Functions or another backend) and call it from the front-end.

    This aligns with the documented behavior: SWA serves static assets and uses configuration-based routing and fallbacks; client-side routes must be covered by a fallback route, and server-side execution is not provided by the static host itself.

    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.