HTTP Status Codes Explained: What 200, 301, 404 and 503 Mean for Monitoring

Every response from a web server starts with a three-digit number. Browsers rarely show it, but for monitoring tools, search engines and API clients it's the most important part of the whole response. HTTP status codes tell you whether a request worked, whether the content has moved, whether the client got something wrong, or whether the server is in trouble.

This article walks through the codes you actually run into, explains how Google handles them, and covers which ones your uptime and link monitoring should treat as failures, and which ones it shouldn't.

The five classes of HTTP status codes

The first digit defines the class. The codes are specified in RFC 9110, the current standard for HTTP semantics.

For monitoring, the rule of thumb is simple: 2xx is good, 3xx needs to be followed, 4xx and 5xx are errors. The details matter, though, because not every 200 is a success and not every 403 is an outage.

2xx: success, at least according to the server

200 OK is the standard response to a successful request. APIs return 201 Created when a resource has been created, and 204 No Content means success with an empty body. Health check endpoints usually answer with 200 or 204.

Keep in mind that a 2xx only says the server believes it handled the request successfully. It says nothing about what's on the page. Plenty of applications catch errors and render a friendly error page while still sending 200. The shop says "Something went wrong", and your monitoring stays green.

Google calls these soft 404s: pages that return 200 but are empty or display an error. Search Console reports them separately. For monitoring, the takeaway is to also check for a keyword on important pages, something that only appears on the real page, such as the label of the add-to-cart button or a marker in the footer. Alternatively, check that a typical error message is absent.

3xx: using redirects correctly

Redirects aren't errors, but they cause a lot of them. The codes that matter:

• 301 Moved Permanently: the resource has moved for good. The standard choice for changed URLs and for moving from http to https or from www to the bare domain.
• 302 Found: a temporary redirect. The original URL remains the canonical address.
• 303 See Other: typically sent after a form submission so the browser loads the result page with GET.
• 304 Not Modified: not really a redirect but an answer to a conditional request. The client may keep using its cached copy.
• 307 Temporary Redirect and 308 Permanent Redirect: like 302 and 301, but with an explicit rule that the client must keep the method and body. With 301 and 302, clients have historically turned a POST into a GET.

Search engines care about permanent versus temporary. According to Google's documentation on HTTP status codes, Google's systems treat 301 and 308 as a strong signal that the redirect target should be processed, and 302 and 307 as a weak signal. By default, Google's crawlers follow up to ten redirect hops.

In practice, the trouble comes from redirect chains and redirect loops. After a few redesigns, an old link goes through http, www, an old category and a new category before it reaches its destination four hops later. Every hop adds latency, and sooner or later one rule points to another that points right back. Always redirect straight to the final URL, and update internal links instead of relying on redirects. We describe a systematic process for this in How to Find Broken Links and Protect Your SEO.

4xx: client errors, which aren't always outages

A 4xx means the server thinks something is wrong with the request. That's not automatically a problem with your site.

• 400 Bad Request: the request is malformed, for example invalid parameters or a broken header.
• 401 Unauthorized: despite the name, this is about missing or invalid credentials. A protected API returns 401 when called without a token.
• 403 Forbidden: the server refuses access, even with credentials. Firewalls and bot protection often answer automated requests with 403.
• 404 Not Found: nothing exists at this address, or at least not anymore.
• 405 Method Not Allowed: the method isn't allowed for this URL. Some servers reject HEAD even though GET works fine.
• 410 Gone: the page was removed deliberately and permanently.
• 429 Too Many Requests: rate limiting. The client sent too many requests and should wait, often as indicated by a Retry-After header.

Google treats every 4xx code except 429 the same way: the content isn't used, and URLs that were already indexed drop out of the index over time. 429, on the other hand, is treated like a server error and makes Google slow down crawling. For SEO, that means a 404 on a page with visitors and backlinks costs you visibility, while a 404 on a URL that never existed is perfectly normal. If you remove a page on purpose and there's no replacement, 410 is the more honest answer. If there is a successor page, a 301 redirect is better.

For monitoring, what matters is who's asking. On your own pages, a 404 on the home page or the checkout is a real failure. On links to other websites, you'll often get 401, 403 or 429 because the other server blocks automated requests, even though the page works fine for humans. A good link monitor doesn't count those responses as broken for external links; otherwise the report fills up with false alarms.

5xx: the server has a problem

The 5xx class is what most people mean by an outage.

• 500 Internal Server Error: an unhandled error in the application, such as an exception, a failed database query or a configuration mistake.
• 502 Bad Gateway: a proxy or load balancer didn't get a valid response from the server behind it. Typical when PHP-FPM or a Node process has crashed while Nginx keeps running.
• 503 Service Unavailable: the service is temporarily unavailable, due to overload or maintenance.
• 504 Gateway Timeout: the proxy waited too long for the server behind it.

Google slows down crawling when it sees 5xx responses. Pages that are already indexed stay in the index at first, but they're removed if the error persists. A short outage usually won't hurt your rankings; one that lasts for days can.

If you use a CDN like Cloudflare, you'll also see codes such as 521, 522 or 526. These aren't part of the HTTP standard; they're the provider's own codes. All three mean the CDN couldn't reach your origin server, or couldn't reach it securely, and your monitoring should take them as seriously as a 502.

Maintenance: use 503, not 200

For planned maintenance, 503 is the right code, ideally with a Retry-After header. That tells browsers, crawlers and API clients the situation is temporary. A maintenance page served with 200 can end up indexed as your content, and a 302 redirect to /maintenance confuses search engines and clients alike.

In Laravel, maintenance mode handles this for you: php artisan down responds with 503 by default, and php artisan down --retry=60 also sets the Retry-After header. Other frameworks and web servers offer something similar.

How to check HTTP status codes yourself

For a quick look, curl on the command line is all you need. This prints just the status code of a URL:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com

To see where a URL redirects and how many hops it takes, let curl follow redirects and print the final status, the number of redirects and the final URL:

curl -sIL -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}\n" http://example.com

Run curl -sIL https://example.com without the output options to see the headers of every response in the chain. Note that -I sends a HEAD request. Some servers answer HEAD differently from GET, for example with 405 or even 404. If a result looks odd, double-check with a GET.

Which status codes your monitoring should treat as failures

From the sections above, a few practical rules for uptime monitors follow:

1. Default: 2xx means up, anything else means down. That covers the vast majority of pages.
2. Follow redirects and judge the final response. If you monitor http://, you want to know whether the https page at the end works, not just whether the server sends a 301. Cap the number of hops so loops show up as failures.
3. Set expected codes deliberately. A protected API endpoint should return 401 without credentials. If you monitor it without a token, 401 is the correct answer, and a 200 would be cause for concern.
4. Check the content, not just the code. A keyword check catches soft 404s and swallowed errors that return 200.
5. Set timeouts. A page that returns 200 after 40 seconds is effectively down for your visitors.
6. Confirm failures before alerting. A single 502 during a deployment or one brief timeout isn't an outage. A second check shortly afterwards separates real problems from blips.

Link monitoring follows slightly different rules: 4xx and 5xx on internal links are broken and need fixing, while 3xx isn't an error but a hint to point the link at its final target. For external links, don't count typical bot blocks such as 401, 403 or 429 as broken. For the other checks worth running on a website, see How to Set Up Website Monitoring.

How Kaspar helps

Kaspar's uptime monitors check your pages with GET, HEAD or POST. By default, any 2xx response counts as up. We follow up to five redirects and judge the response at the end of the chain; more hops than that count as a failure. Under "Expected status codes" you choose which codes a monitor should accept instead, and a keyword check verifies that a piece of text is present, or that it's absent. You set the timeout per monitor, anywhere from 1 to 30 seconds. When a check fails, we re-check within seconds and only alert you once the failure is confirmed, by email, Slack or Telegram.

In the same account, you can set up broken-link scans. They follow internal redirects and report links that return 4xx or 5xx or can't be reached at all. External links are checked with HEAD, falling back to GET when the server refuses HEAD, and typical bot blocks from other sites such as 401, 403 or 429 don't count as broken. To check a single page without an account, use our free broken link checker, which also shows which links redirect. See our pricing page for the plans and features for an overview of everything Kaspar does.