Whenever a browser, an app, or a monitoring tool asks a web server for something, the server begins its answer with a status code. It is a short number that sums up the outcome: it worked, go somewhere else, you did something wrong, or the server did.
The first digit gives the class, and the class is usually enough to understand the situation.
The five classes
| Class | Name | Meaning |
|---|---|---|
| 1xx | Informational | The request was received and processing continues. Rarely visible to users. |
| 2xx | Success | The request was received, understood, and accepted. |
| 3xx | Redirection | The client must take another step, usually requesting a different address. |
| 4xx | Client error | The request is wrong or not allowed. The problem is on the requesting side. |
| 5xx | Server error | The request seemed valid, but the server failed to complete it. |
"Client error" does not mean the visitor is to blame. A broken link on your own site produces a 404, and it is still your site's problem to fix.
1xx: informational
These are interim responses. 100 Continue and 101 Switching Protocols are examples. Ordinary page checks almost never meet them, because the final answer follows.
2xx: success
- 200 OK. The request succeeded and the answer contains the content. This is the normal result for a working page.
- 204 No Content. The request succeeded and there is nothing to send back. Common for APIs.
3xx: redirects
A redirect tells the client to ask somewhere else. The new address arrives in the Location header.
- 301 Moved Permanently. The address has changed for good. Browsers and search engines are expected to use the new one. Typical use: moving a site to a new domain, or forcing
https. - 302 Found. A temporary move. Clients should keep using the original address in the future.
- 304 Not Modified. Not a move: the content has not changed, so the client can use its cached copy.
There are two more pairs worth knowing. 308 and 307 behave like 301 and 302 but guarantee that the request method and body stay the same, which matters for forms and APIs.
Each redirect costs an extra round trip, and a chain of redirects (A to B to C) adds one per step. A redirect loop, where the destination leads back to the start, never reaches a page, and browsers eventually stop with an error.
4xx: client errors
- 401 Unauthorized. The request lacks valid credentials. Despite the name, it means "not authenticated": log in, or send valid credentials, and try again.
- 403 Forbidden. The server understood the request and refuses it. The client may be known but is not allowed, and signing in again will not change that.
- 404 Not Found. There is nothing at this address. A server may also return 404 to hide a page from people who are not allowed to see it.
- 429 Too Many Requests. The client sent too many requests in a given time. The response may include a
Retry-Afterheader saying how long to wait.
5xx: server errors
- 500 Internal Server Error. A general failure. The server hit something it could not handle, often a bug or a misconfiguration.
- 502 Bad Gateway. A server acting as a gateway or proxy received an invalid response from the server behind it.
- 503 Service Unavailable. The server cannot take the request right now, for example because of maintenance or overload. It is meant for temporary conditions and may carry a
Retry-Afterheader. - 504 Gateway Timeout. A gateway or proxy waited too long for the server behind it.
For reading outages, 502, 503, and 504 usually mean a problem between layers: the proxy in front is working, and what it forwards to is not.
Why status codes matter for monitoring
A status code is the quickest check that a site is answering and answering correctly. It separates different problems that look alike to a visitor:
- No code at all (timeout, refused connection, DNS error): the server could not be reached.
- 5xx: the server was reached and failed.
- 4xx on a page that should work: a missing page, a permission problem, or a block against the requester.
- 3xx where you expected 200: a redirect that may have been added, removed, or broken.
Tracking codes over time also shows patterns. A single 503 during a deployment is different from 503 every night at the same hour.
Redirects in monitoring
A check that requests an address needs a rule for redirects. Treating a 301 as a failure would make every site that redirects http to https or example.com to www.example.com look broken. So most tools follow redirects and judge the final answer, with a limit on how many hops they follow so a loop cannot run forever.
How UptimeWire judges a response
UptimeWire sends a GET request to the address you configured and follows redirects, up to five. It then looks at the final answer:
- 200 to 399 counts as available. That includes 2xx success codes and 3xx answers where it does not go further.
- Everything else is a failure. This includes 404, 429, 500, 502, 503, and 504.
- 401 and 403 are failures too. A monitored page that asks for a login, or blocks the request, is reported as failed rather than treated as healthy. If you monitor a page behind authentication, choose a public address such as a health page.
- More than five redirects is a failure, as is no answer, a connection error, a DNS failure, or an invalid certificate.
Success on the wire is not a healthy application
A 200 means the server answered successfully. It does not mean the page is correct. A broken checkout that still renders a normal page, an empty page where data should be, or an error message in the body of a "200" response all pass an HTTP check. See downtime for what such a check can and cannot see. UptimeWire does not run full browser-based tests. It checks the answer to a request.
Troubleshooting by code
| You see | Likely direction |
|---|---|
| 404 on a page that existed | A deleted or renamed page, a changed URL structure, or a deployment that missed files |
| 403 on the home page | A firewall or security rule, a permission change on files, or a block of the checking tool's address |
| 401 on a public page | Authentication was added to a path that used to be open |
| 429 | A rate limit. Many requests from one source, including checks, may trigger it |
| 500 | Look at the application logs: a code error, a failed dependency, or a bad configuration |
| 502 | The service behind the proxy is down, crashed, or restarting |
| 503 | Maintenance or overload. Check resource usage and whether a deployment is running |
| 504 | The service behind the proxy is too slow. Look at long-running requests and the database |
| Redirect loop | Two rules sending requests back and forth, often http and https or www settings |
When a code appears, also look at response time. A rise in response time often comes just before 504 or 503 errors begin.