HTTP Status Codes Explained for Monitoring

Every time your browser requests a web page, the server sends back a three-digit number along with the response. That number is the HTTP status code, and it tells the browser (and any monitoring tool) what happened with the request. Did it succeed? Did the page move? Is the server broken?

If you are monitoring a website's uptime, understanding status codes is essential. They are the primary signal your monitoring tool uses to decide whether your site is "up" or "down." A 200 means everything is fine. A 500 means something is broken. But there are dozens of codes in between, and some of them are more nuanced than they first appear.

How Status Codes Work

When a client (a browser, an API consumer, or a monitoring tool) sends an HTTP request to a server, the server processes the request and sends back a response. That response includes:

• A status code (a three-digit number)
• A reason phrase (a short text description like "OK" or "Not Found")
• Headers (metadata about the response)
• An optional body (the actual content)

The status code is the most important part for monitoring purposes. It gives an immediate, machine-readable signal about the outcome of the request.

Status codes are grouped into five classes based on their first digit:

• 1xx: Informational
• 2xx: Success
• 3xx: Redirection
• 4xx: Client error
• 5xx: Server error

For monitoring, you care most about 2xx (good), 3xx (usually fine but worth tracking), 4xx (sometimes a problem), and 5xx (always a problem).

2xx Success Codes

These codes mean the request was received, understood, and processed successfully. In monitoring terms, a 2xx response means your site is working.

200 OK

The standard success response. The server processed the request and returned the requested content. This is what your monitoring tool wants to see on every check.

When you set up an uptime monitor, the baseline expectation is a 200 response. If your check URL returns 200, your site is up. Simple.

201 Created

The request succeeded and a new resource was created. You see this with POST requests, like when a form submission creates a new record. Less relevant for basic uptime monitoring but important if you are monitoring API endpoints.

204 No Content

The request succeeded but the server has no content to send back. Common for DELETE requests and some API operations. The site is working; there is just no body in the response.

202 Accepted

The request has been accepted for processing but is not yet complete. Used for asynchronous operations. The server is working, but the task will finish later.

3xx Redirection Codes

These codes mean the requested resource has moved. The server is telling the client to look somewhere else. Redirects are normal, but they matter for monitoring.

301 Moved Permanently

The resource has permanently moved to a new URL. The server includes the new URL in the response. Browsers and search engines should update their records to use the new location.

For monitoring: if your check URL returns a 301, your monitoring tool should follow the redirect and check the destination. Most monitoring services do this by default. If the final destination returns 200, your site is up. But watch for redirect chains (301 to 301 to 301) that add latency.

302 Found (Temporary Redirect)

The resource is temporarily at a different URL. The client should continue using the original URL for future requests.

Common scenario: your site redirects HTTP to HTTPS. A check against http://yoursite.com gets a 302 to https://yoursite.com. This is normal and expected. Your monitoring tool should follow the redirect.

304 Not Modified

The resource has not changed since the client last requested it. The server tells the client to use its cached copy. This is an optimization, not an error. It means the server is working correctly and efficiently.

307 Temporary Redirect

Similar to 302, but the request method must not change. If the original request was a POST, the redirect must also be a POST. This distinction matters for API monitoring but not for basic website checks.

308 Permanent Redirect

Similar to 301, but the request method must not change. Increasingly common for HTTPS redirects where preserving the request method matters.

4xx Client Error Codes

These codes mean the request was invalid in some way. The server understood the request but refuses to fulfill it. For monitoring purposes, 4xx codes can indicate either a normal condition or a real problem, depending on context.

400 Bad Request

The server cannot process the request because the client sent something malformed. If your monitoring tool gets a 400, the check URL or request configuration might be wrong. This usually indicates a monitoring configuration problem, not a site problem.

401 Unauthorized

The request requires authentication. The server is saying "who are you?" This is normal for protected pages. If your monitoring check targets a page behind authentication and you have not provided credentials, you will see 401s.

For monitoring authenticated pages, configure your monitoring tool to send valid credentials (HTTP basic auth, API keys, or session tokens).

403 Forbidden

The server understood the request but refuses to authorize it. Unlike 401, authenticating will not help. The server knows who you are and says no.

For monitoring, 403s can mean your monitoring tool's IP address is blocked by a firewall, a WAF (Web Application Firewall), or a rate limiter. If you suddenly start getting 403s from a page that used to return 200, check whether a security rule is blocking your monitoring service's requests.

404 Not Found

The requested resource does not exist at the given URL. This is the most familiar error code for most people.

For monitoring, a 404 on your homepage or a critical page means something is seriously wrong, either the page was deleted, the URL changed, or the routing configuration is broken. A 404 on a deep link might just mean the content was removed intentionally. Configure your monitoring checks against URLs that should always exist.

405 Method Not Allowed

The HTTP method used (GET, POST, PUT, etc.) is not supported for the requested URL. If your monitoring tool sends a GET request and the server only accepts POST, you get a 405. Check your monitoring configuration.

408 Request Timeout

The server timed out waiting for the client to finish sending the request. Not common in monitoring, but if you see it, it might indicate network problems between your monitoring service and your server.

429 Too Many Requests

The client has sent too many requests in a given time period. This is rate limiting in action. If your monitoring service checks too frequently or from too many locations simultaneously, the server might rate-limit it.

If your monitoring tool gets 429s, you have a few options: reduce check frequency, whitelist the monitoring service's IP addresses in your rate limiter, or configure your rate limiter to exempt monitoring requests.

5xx Server Error Codes

These codes mean something went wrong on the server. For monitoring, any 5xx response means your site is having problems. These are the codes that should trigger alerts.

500 Internal Server Error

A generic error indicating the server encountered an unexpected condition. This is the catch-all for server-side failures. Bugs in your application code, database connection failures, misconfigured server settings, and many other issues can produce a 500.

When your monitoring tool reports a 500, check your application logs. The 500 code itself does not tell you what went wrong; your logs will.

502 Bad Gateway

The server, acting as a gateway or proxy, received an invalid response from an upstream server. This is common in architectures where a reverse proxy (like Nginx) sits in front of an application server. If the application server crashes, Nginx returns 502 to clients.

A 502 often means your application process is down but your web server is still running. Restart the application process, check for crashes or resource exhaustion.

503 Service Unavailable

The server is temporarily unable to handle the request. Common causes: the server is overloaded, the server is in maintenance mode, or a dependency is unavailable.

Many servers return 503 during deployments or planned maintenance. If your monitoring tool reports a 503 that resolves quickly, it might just be a deployment. If it persists, the server is genuinely struggling. For ways to minimize downtime during maintenance, see planned vs unplanned downtime.

504 Gateway Timeout

The server, acting as a gateway, did not receive a timely response from the upstream server. Similar to 502, but the upstream server did not respond at all (instead of responding with an error).

A 504 typically means your application is alive but taking too long to process the request. Check for slow database queries, external API timeouts, or resource contention. See what is latency for more on diagnosing slow responses.

520-530 (Cloudflare-Specific Codes)

If your site is behind Cloudflare, you might encounter status codes in the 520 to 530 range. These are Cloudflare-specific codes indicating problems between Cloudflare and your origin server.

• 520: Unknown error. Cloudflare received an unexpected response from the origin.
• 521: Web server is down. Cloudflare cannot connect to the origin.
• 522: Connection timed out. Cloudflare's connection to the origin timed out.
• 523: Origin is unreachable. DNS or routing issues prevent Cloudflare from reaching the origin.
• 524: A timeout occurred. The origin did not respond within Cloudflare's timeout window.

These codes all indicate origin server problems. Your site appears down to users even though Cloudflare's network is functioning.

Status Codes and Monitoring Configuration

When setting up your uptime monitoring, consider these configuration details:

Expected status code. Set your monitoring check to expect the correct status code. If your URL redirects, the "correct" code might be 301 or 302 before the final 200. Most tools follow redirects and check the final response.

Redirect following. Ensure your monitoring tool follows redirects. A 301 is not an error, but a monitoring tool that does not follow redirects might flag it as one.

Content verification. Status codes alone can be misleading. A server might return 200 but serve an error page (a "soft 404" or a maintenance page). Add keyword checks that verify the response body contains expected content. See the uptime monitoring guide for setup details.

Timeout thresholds. If the server takes too long to respond, your monitoring tool eventually times out. Set a reasonable timeout (10 to 30 seconds) that matches what your users would tolerate. A response that takes 25 seconds is technically successful but practically unusable.

Key Takeaways

• HTTP status codes are three-digit numbers that indicate the outcome of a web request.
• 2xx codes mean success. 200 OK is what your monitoring tool expects to see.
• 3xx codes are redirects. Normal, but your monitoring tool should follow them and check the final destination.
• 4xx codes are client errors. Check your monitoring configuration if you see these unexpectedly.
• 5xx codes are server errors. These should always trigger alerts.
• Pair status code checks with content verification to catch cases where the server returns 200 but serves unexpected content.