HTTP Status Codes Cheat Sheet for Website Monitoring

For uptime monitoring, the short answer is: 2xx responses mean up, 5xx responses mean down, and everything in between depends on what you expect from that URL. A 301 is fine if the page has moved on purpose, a 401 is fine on an API endpoint that requires a key, and a 404 on your checkout page is an outage. The right monitor checks for the status code you expect, not just for “anything but an error”.

This cheat sheet goes through the status code families from a monitoring point of view: what each code means, whether it should count as down, and how to set up checks so they alert on real problems only.

The five families at a glance

Range	Meaning	For a monitor
1xx	Informational, the request continues	Rarely seen; not a final answer
2xx	Success	Usually up
3xx	Redirect, look elsewhere	Up or down depending on intent
4xx	Client error, the request was wrong	Depends on the endpoint
5xx	Server error, the server failed	Down

The first digit tells you who is responsible. 4xx means the server thinks the request was wrong. 5xx means the server admits it failed. For a monitor that sends the same request every minute, a sudden 4xx usually means something changed on the server side anyway: a page was removed, a permission changed or a firewall started blocking.

1xx: informational

Codes such as 100 Continue, 101 Switching Protocols and 103 Early Hints are interim responses. A client sees them before the final answer, or not at all. A monitoring check waits for the final status code, so you can ignore this family. If a check ever ends on a 1xx, the connection was cut off mid-response, which is a failure.

2xx: success

Code	Name	Notes for monitoring
200	OK	The standard success response
201	Created	Expected after a POST that creates something
202	Accepted	Request queued; work happens later
204	No Content	Success with an empty body; common for DELETE and some health checks

A 200 is not a guarantee that the page works. Many applications catch their own errors and render an error page with status 200: “Database connection failed”, a blank template, a maintenance notice. Add content validation to important checks: expect a word or a JSON field that only appears when the page really works. With 204, there is no body to validate, so check the status code only.

3xx: redirects

Code	Name	Typical use
301	Moved Permanently	Old URL to new URL, HTTP to HTTPS
302	Found	Temporary redirect, often to a login page
303	See Other	Redirect after a form POST
304	Not Modified	Cached copy is still valid; only after conditional requests
307	Temporary Redirect	Like 302, but keeps the method and body
308	Permanent Redirect	Like 301, but keeps the method and body

Redirects and monitors

Monitoring tools handle redirects in one of two ways: they follow them and report the status of the final page, or they stop at the first response and report the 3xx. Know which one your tool does for each check, because both can hide problems:

• If the monitor follows redirects, a page that suddenly redirects to the homepage or a login screen can still end in a 200. Content validation catches this: the homepage does not contain the words of your checkout page.
• If the monitor does not follow redirects, set the expected status to the redirect code, and check the final URL with its own monitor.

The safest pattern is to monitor the final URL directly. If northwind.shop redirects to www.northwind.shop, monitor the www version, and add a separate check for the redirect only if it matters to you, for example for old campaign links. A redirect loop, where two URLs point to each other, shows up as a timeout or a “too many redirects” error and should always count as down.

4xx: client errors

Code	Name	Down?
400	Bad Request	Usually a broken check or a changed API
401	Unauthorized	Expected on protected endpoints without credentials
403	Forbidden	Expected for blocked paths; a problem if it appears suddenly
404	Not Found	Down for any URL that should exist
405	Method Not Allowed	The check uses the wrong method, or the route changed
408	Request Timeout	The server gave up waiting for the request
410	Gone	Removed on purpose
429	Too Many Requests	Rate limited

401 and 403 on protected endpoints

Some endpoints should refuse anonymous requests. An admin API that returns 401 without a token is working correctly. You can monitor it two ways:

1. Expect the refusal. Set the expected status to 401. The check confirms the server is up and the auth layer is in place. If it ever returns 200 without credentials, that is a security problem worth an alert.
2. Send credentials. Add an API key header or basic auth to the check and expect 200 plus the right content. This tests the full path, including the database behind the endpoint.

The second option tests more, so use it for anything customers rely on. Use a dedicated read-only key for monitoring, never a personal or admin key.

A sudden 403 on a public page is a different story. It usually means a firewall, a security plugin or a CDN rule has started blocking requests, sometimes only from certain countries or IP ranges. If one monitoring location gets 403 and another gets 200, a geo or IP rule is the likely cause.

429 Too Many Requests

A 429 means the server is rate limiting the client. For monitoring it means one of two things: your limits are too strict for normal traffic, or the monitor itself is hitting a limit because it shares an address with other clients. Check the Retry-After header and your rate limit configuration. If real users are getting 429s at normal load, treat it as an outage.

5xx: server errors

Code	Name	What it usually means
500	Internal Server Error	The application crashed on this request
501	Not Implemented	The server does not support the method
502	Bad Gateway	The proxy got an invalid response from the app behind it
503	Service Unavailable	Overloaded, in maintenance or no healthy backend
504	Gateway Timeout	The proxy waited too long for the app

Treat every 5xx as down. The codes differ in where to look first: a 500 points to application logs, a 502 to a crashed or restarting application process, a 504 to slow queries or external calls, and a 503 to capacity or maintenance. Our guide to the 503 Service Unavailable error goes through the causes and fixes in detail.

Some CDNs and proxies use their own codes in the 5xx range, such as 520 to 530, for problems between the CDN and your origin server. They are not part of the HTTP standard, but they mean the same thing to a visitor: the site is down.

Not every failure has a status code

Some of the most common outages never produce a status code at all:

• DNS failure: the domain does not resolve, for example after a lapsed registration or a removed record.
• Connection refused or reset: nothing is listening on the port, or a firewall drops the connection.
• TLS errors: an expired or mismatched certificate stops the request before any HTTP happens.
• Timeouts: the server accepts the connection but never answers in time.

A good monitor reports these as failures with the actual error, so the alert says “certificate expired” rather than just “down”. That is also why it is worth adding certificate and domain expiry checks next to your HTTP monitors.

How to set the expected status in a monitor

For each URL you monitor, decide what a healthy response looks like and write it down as the check configuration:

1. Choose the URL that matters. The final URL after redirects, not the short link.
2. Set the method. GET for pages, and whatever the endpoint requires for APIs.
3. Set the expected status. Usually 200. Use 201, 204, 301 or 401 when that is the intended answer.
4. Add credentials if needed. Headers or basic auth for protected endpoints.
5. Add content validation. A word on the page or a field in the JSON response that only appears when everything works.
6. Set a timeout. A response that takes 30 seconds is a failure for a visitor even if it ends in 200.

Here is what that looks like for a health endpoint on lumenanalytics.io, tested by hand first with curl:

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" \
  -H "Authorization: Bearer $MONITOR_TOKEN" \
  https://api.lumenanalytics.io/v1/health

If that prints 200 and a reasonable time, the same method, header and expected status go into the monitor. In Uptimecheck, uptime monitors and API monitors accept a custom method, headers, body and basic auth, and fail the check when the status code or the response is not what you expect. For more on designing the endpoint itself, see how to build a health check endpoint, and the API monitoring checklist for which endpoints to cover.

Quick reference: is it down?

• Down: any 5xx, a 404 on a URL that should exist, timeouts, DNS and TLS errors, refused connections.
• Probably down: a sudden 403 or 429 on a public page, a 400 or 405 on a check that used to pass.
• Up: the status code you configured as expected, with the content you validate for, in reasonable time.

Summary

Status codes are the first thing a monitor looks at and the quickest way to tell where a problem lives. 5xx means the server failed, 4xx means something changed about what the server accepts, and 3xx needs a decision about where the check should end. Configure each monitor with the status it should get, validate the content of important pages and let the alert carry the code, so whoever picks it up knows where to start.

Uptimecheck checks your websites and APIs as often as every minute and alerts you when the status code or the response is not what you expect. Try it free for 14 days, no credit card required.