Error guide
4xx client errors
The class of responses that means the request was at fault. For a monitor, a 4xx usually means the check is misconfigured.
4xx errors are the client-error class of HTTP status codes, 400 to 499. A 4xx says the server understood the request and refused it because the request itself was the problem: malformed, unauthorized, aimed at something that does not exist, or using a method that is not allowed. The server is working and answering. It is saying the question was wrong.
The codes you will meet most often are 400 Bad Request (the request was malformed), 401 Unauthorized (no valid credentials were sent), 403 Forbidden (access is refused, with or without credentials), 404 Not Found (nothing lives at that path), 405 Method Not Allowed, 410 Gone and 429 Too Many Requests. Each one has a different fix, so read the exact code before anything else.
That makes the class unusual in monitoring. A 4xx on a check normally points at the check, not the service. A monitor that gets 401 has lost its credentials. One that gets 404 is pointed at a path that moved. One that gets 405 is using the wrong method. Paging the on-call for these produces an alert about a monitoring setting, which is the kind of alert that teaches people to ignore alerts.
Two codes in the class break that rule and are worth treating as real failures. A 429 means the server is deliberately shedding load, which is a capacity signal about the service. A 408 means the server gave up waiting for the request to arrive, which usually says more about the network or the server's own load than about the client. Both have their own guides.
4xx versus 5xx comes down to who the status code blames. A 4xx blames the request, a 5xx says the server failed on a request that looked valid, and the first digit alone decides the class (RFC 9110). That is why 408 Request Timeout, which people often file with server errors because it says timeout, is a 4xx: the server timed out waiting for the client to finish sending. A timeout while waiting on an upstream server is the 5xx 504 instead.
Common causes
- The check is pointed at a URL that has moved, been renamed, or was never right.
- Authentication the check sends has expired, been rotated, or was never configured.
- The request method, headers or body do not match what the endpoint expects.
- A WAF, bot filter or rate limiter is rejecting the monitor specifically, while real traffic passes.
- The endpoint returns a 4xx on purpose as part of normal operation, and the check treats it as a failure.
How to diagnose it
- Read the exact code, not just the class. 401, 403, 404, 405 and 429 have completely different fixes.
- Reproduce the check's request from somewhere else with curl, including its headers and method.
- Compare it to a request a real client makes. The difference is almost always the answer.
- Check the server's access log for the monitor's request and see what it recorded.
- If the request works from your machine and not from the monitor, suspect an IP or user-agent filter.
Whose fault is it? Usually the client's side
By definition the request is at fault. In monitoring that almost always means the check needs fixing rather than the service. The two exceptions worth investigating on the server side are 429 and 408.
What monitoring sees
By default an Uptimely check passes only when the response status is between 200 and 399, so any 4xx fails it. The exact code is recorded with the check, so the failure reads as a 401 or a 404 rather than a generic error. If an endpoint answers with a 4xx on purpose, change the monitor's criteria to check the response status code you expect, rather than leaving it to page every night. By default an incident is declared only after two failed checks in a row. A 408 is no different: it is recorded as status 408 and fails the check like any other status outside that range.
Related error guides
Terms used on this page
Questions
What is the difference between a 4xx and a 5xx error?
A 4xx error means the request was at fault and the server refused it, so the fix is usually on the client or on the check. A 5xx error means the request was valid and the server failed to handle it, so the fix is on the server. The line is the class, not the symptom: a 408 Request Timeout is a 4xx because the server was waiting for the client's request, while a 504 Gateway Timeout is a 5xx because a gateway was waiting for an upstream server.
Is 408 a server error or a client error?
A 408 Request Timeout is a client error, a 4xx, not a 5xx server error. RFC 9110 defines it as the server not receiving a complete request within the time it was prepared to wait, so the status blames the request arriving too slowly. The cause can still sit on the server or the network: a slow link, a client uploading a large body, or a server with a short read timeout. A monitor reports it as status 408 and, by default, fails the check, because only responses from 200 to 399 pass unless you change the monitor's criteria.
Should a monitor treat every 4xx as downtime?
No. A 4xx usually means the check is wrong, not the service, and paging for it trains the team to ignore alerts. The exceptions are 429 and 408, which describe the server's capacity rather than the request's correctness.
Why does my monitor get a 4xx when my browser does not?
Almost always a difference in the request. Missing cookies or auth headers, a different user-agent, or a bot filter that lets a browser through and blocks a data center IP. Reproduce the monitor's exact request with curl to see which.
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.