HTTP Status Codes: 404 and 500 Explained

An HTTP status code tells the client how the server handled a request. 404 Not Found means no matching resource (or you are not allowed to know it exists). 500 Internal Server Error means the server hit an unexpected failure while processing. Confusing them wastes hours — caching a 404 will not fix a crashing app.

404 vs 500 at a glance

Code	Class	Typical cause
404	4xx client	Wrong URL, deleted page, bad route
403	4xx client	Authenticated but forbidden
500	5xx server	Unhandled exception, misconfig
502/503	5xx server	Bad gateway / unavailable upstream

APIs sometimes return 404 for “ID not in database” and 400 for validation errors — check your API’s conventions.

Debugging checklist

1. Reproduce with curl or DevTools; note method and path.
2. For 404 — verify routing, trailing slashes, deploy output, CDN rules.
3. For 500 — read server logs, recent deploys, dependency outages.
4. Confirm you are not caching an old error response.

Reference on TryDevSnip

Browse TryDevSnip HTTP Status Codes or jump to HTTP 404 and HTTP 500 explainers. Use them as a quick glossary while debugging.

Privacy one-liner: the reference pages are static and run in your browser; not uploaded to our servers for processing.

Related: URL Encode when bad encoding produces odd paths that 404.

FAQ

Should APIs use 404 or 400 for missing IDs?

Both exist in the wild. 404 is common for “resource not found”; document your choice.

Is 500 ever the client’s fault?

Usually not — but bad input that trips an unhandled bug surfaces as 500. Fix the server to return 4xx for expected validation failures.

What about 204 and 201?

Success codes: 201 Created, 204 No Content. Different class from errors.

Why do I see 404 from a CDN for a working origin?

CDN path rules, case sensitivity, or the edge never fetched the new object after deploy.