What this usually means
The server is running, but the request is not reaching your route handler. The most common cause is a path mismatch: your code defines `/api/users` but the deployment platform adds a base path prefix, or a reverse proxy rewrites the URL before it reaches your app. Another common cause: the route file is not included in the production build because of a build config or tree-shaking issue. The route exists in your source code — it just does not exist in the running production process.
The first ten minutes \u2014 establish facts before touching code.
- 1Check if the server logs the incoming request. If no log appears, the request is not reaching your app — check the reverse proxy or load balancer.
- 2Add a catch-all route that logs every incoming request path. Deploy and hit the missing endpoint. Compare the logged path to what you expect.
- 3Check if the deployment platform adds a base path. Vercel, for example, can add `/api` prefix. Your route `/api/users` might need to be just `/users`.
- 4Verify the production build includes the route file. If using a framework with file-based routing (Next.js, SvelteKit, Nuxt), check the build output.
- 5Check route ordering. A wildcard or catch-all route defined before your specific route can swallow the request.
The specific files, logs, configs, and dashboards that usually own this bug.
- searchServer startup logs — does it print the registered routes? Compare local vs production.
- searchBuild output — is the route file in the compiled output?
- searchReverse proxy config (Nginx, Caddy, Traefik) — URL rewriting rules
- searchDeployment platform's routing config (Vercel `vercel.json`, Netlify `_redirects`, Cloudflare Workers routes)
- searchFramework routing config (Next.js `middleware.ts`, Express router mounting paths)
- searchEnvironment variable that controls a base path or API prefix
Practical causes, not theory. These are the things you will actually find.
- warningDeployment platform adds a base path prefix that your route does not account for
- warningReverse proxy rewrites or strips path segments before forwarding to the app
- warningRoute file is excluded from production build due to conditional import or tree-shaking
- warningRoute is mounted under a prefix locally but the production server mounts it differently
- warningThe production URL has a different casing than expected (some servers are case-sensitive)
- warningA middleware or guard rejects the request before it reaches the route handler
- warningThe deployment uses a serverless function and the route is not configured as a function entrypoint
Concrete fix directions. Pick the one that matches your root cause.
- buildAdd a startup route dump: iterate all registered routes and log them. Compare local vs production output.
- buildUse relative route definitions that do not hardcode a base path. Let the framework or env var provide the base.
- buildAdd a catch-all debug route temporarily in a staging deploy. Log the full request URL, path, and headers.
- buildCheck the platform's routing documentation. Many platforms auto-wrap or prefix routes.
- buildVerify the production build pipeline includes the route file by checking the build manifest or output directory.
A fix you cannot prove is a guess. Close the loop.
- verifiedDeploy to staging. Hit the route. Confirm 200.
- verifiedCheck startup logs show the route is registered with the expected path.
- verifiedHit the catch-all debug route to confirm the request path reaching the server matches expectations.
- verifiedTest from an external client (not the same machine) to rule out local network quirks.
- verifiedRun the production build locally (`npm run build && npm start`) and test the route.
Things that make this bug worse or harder to find.
- warningAdding a duplicate route definition instead of finding why the existing one is unreachable
- warningAssuming the production server mounts routes the same way as the local dev server
- warningNot checking the build output — the route file might not be included at all
- warningHardcoding a base path that differs between environments
- warningTesting only from the same machine or network as the server