Error guide

404 Not Found

The server has nothing at that path — and it will not say whether it never did or no longer does.

A 404 Not Found says the server has no resource at the requested path. It is deliberately uninformative about why: it does not distinguish never existed from deleted from you cannot see it. That ambiguity is a feature, since it avoids confirming the existence of things a caller should not know about.

For a site operator the interesting 404s are the ones that changed. A single 404 is usually a bad link somewhere on the internet. A sudden rise in 404s after a deploy means routing broke — a rewrite rule that stopped matching, a build that did not emit a page, a base path that moved, an asset manifest that no longer matches the HTML being served.

The mistake worth avoiding on the serving side is answering a missing page with a 200. A friendly not-found page returned with a success status is invisible to every monitor and every crawler: search engines index it as real content, and an uptime check that asserts only on the status code reports a completely broken route as healthy.

Common causes

  • A deploy that changed routes, renamed a path, or dropped a page from the build output.
  • A rewrite or redirect rule that stopped matching after a configuration change.
  • Case sensitivity: a path that works on a developer's machine and not on a Linux server.
  • Static assets referenced with a stale hash after a partially propagated deploy.
  • A reverse proxy stripping or failing to strip a path prefix.
  • An external link, from a search result or another site, pointing at a URL that legitimately no longer exists.

How to diagnose it

  1. Check whether the request reached the application at all, or was answered by the web server or CDN.
  2. Compare the failing path against the routing table or rewrite rules — including trailing slashes and case.
  3. Look at when the 404s started and what deployed at that moment.
  4. Group the 404 paths in your access log: one path failing is a link problem, a whole prefix failing is a routing problem.
  5. Confirm the page genuinely returns 404 and not a 200 with a not-found body, which hides the problem from every tool.

Whose fault is it? It depends which layer

A 404 for a URL that never existed is the client following a bad link. A 404 for a URL you publish, or one that used to work, is a server-side routing problem — and if you removed the page deliberately, it should be a 410 instead.

What monitoring sees

Uptimely records the status code, so a monitor that starts returning 404 shows the code rather than a generic failure. This is also the strongest argument for content assertions: a check that only requires a 200 will pass against a not-found page served with the wrong status, so a monitor on any page that matters should also assert on a string that appears only when the page really rendered.

Related error guides

Terms used on this page

Questions

Should a deleted page return 404 or 410?

410 if you know it is gone permanently and are not bringing it back — it tells crawlers to drop it much faster. 404 for everything else, including anything you might restore.

Why does my monitor pass while the page is broken?

Most often because the site serves its error page with a 200 status. A status-code check cannot see that. Add a content assertion for a string that only appears when the page really rendered.

One of the Uptimely HTTP and network error guides, written for the person who operates the server rather than the one refreshing the page. Something here read wrong to you? Email support@getuptimely.com.