HTTP 404 means an HTTP service answered the request but could not find the requested resource. DNS, the network connection, and usually TLS worked; the problem is the exact path or the way that path is routed.
Uptime Basics records an unaccepted 404 as a failed check with the Client error diagnosis. The monitor becomes Down only after the normal consecutive and regional confirmation requirements are met.
Confirm the exact URL
- Open Detailed Logs and confirm that the HTTP column shows 404.
- Copy the exact monitored URL, including its path and query string.
- Test it in a private browser window where you are not signed in.
- Compare the failing timestamp with deployment, CDN, proxy, and application logs.
- Check whether a redirect sends the monitor to a missing final page.
Testing only the homepage is not enough. https://example.com can work while https://example.com/health returns 404.
Common causes
The path changed or was removed
A deployment, content update, API version change, or route rename can remove the monitored path. Update the monitor to a stable replacement only after confirming that the new path represents the same service.
A spelling, case, or trailing-slash difference
Some servers treat /Health, /health, /health/, and /health?ready=true as different resources. Compare the saved URL with the route configured at the origin.
The CDN and origin use different routes
A CDN, reverse proxy, load balancer, or web server may not forward the path to the expected application. Review path-based routing, rewrite rules, origin selection, and virtual-host configuration.
A single-page application relies on browser routing
A browser can load a client-side route after JavaScript starts even though a direct HTTP request to that route returns 404. Configure the server to serve the application entry page for valid routes, or monitor a server-backed health endpoint.
The endpoint requires authentication
Some applications deliberately return 404 instead of 401 or 403 for protected resources. Test without an existing browser session. If the endpoint supports HTTP Basic Authentication, configure it under Advanced Request Options. Interactive sign-in pages are not supported.
Should you accept HTTP 404?
Accept 404 only when that exact response is the documented healthy result for the monitored endpoint. For example, a specialized API route may intentionally return 404 for a known lookup while still proving that its gateway is reachable.
For a normal webpage or health endpoint, accepting 404 usually hides a broken path. A purpose-built endpoint that returns HTTP 200 when healthy provides a clearer result.
If 404 is added to Accepted HTTP status codes, future 404 responses count as Up and no Client error diagnosis is recorded for those checks. The change does not rewrite earlier history.
After correcting the route
Keep the existing monitor so its checks and incident history remain available. The next successful check resets the pending failure count or resolves the active incident. The dashboard may need one automatic refresh cycle to display the new state.
When to contact Support
Contact Support if the exact public URL returns a successful response from independent networks but Uptime Basics continues to receive 404.
Include the monitor name, exact URL, timestamps, request method, redirect setting, and any recent route or deployment changes. Do not include passwords, authorization values, cookies, private keys, or verification codes.