Understanding HTTP Status Codes for Website Monitoring

Every time a browser, search engine crawler, or monitoring service requests a page from your web server, the server responds with an HTTP status code. This three-digit number is the server's way of communicating what happened with the request: whether it succeeded, whether the client needs to do something different, or whether something went wrong.

Status codes are grouped into five classes, each identified by the first digit:

• 1xx (Informational) — The request was received and processing continues. You will rarely encounter these in monitoring.
• 2xx (Success) — The request was successfully received, understood, and accepted.
• 3xx (Redirection) — The client needs to take additional action to complete the request, typically following a redirect to a different URL.
• 4xx (Client Error) — The request contains an error or cannot be fulfilled. The problem is on the client side.
• 5xx (Server Error) — The server failed to fulfil a valid request. The problem is on the server side.

For website monitoring, status codes are one of the most fundamental signals. They tell you instantly whether your server is responding correctly, whether pages have moved, or whether something has broken. A monitoring system that tracks status codes over time provides a clear picture of your infrastructure's health and can detect problems ranging from misconfigured redirects to complete server failures.

Understanding what each code means, and which ones warrant an alert, is essential for configuring monitoring that catches real problems without drowning you in noise. This guide covers every status code you are likely to encounter in a monitoring context and explains exactly how to respond to each one.

The 2xx class of status codes indicates that the client's request was received, understood, and processed successfully. In a monitoring context, these are the codes you want to see.

200 OK

The most common status code and the one your monitors should expect for most pages. A 200 response means the server processed the request successfully and returned the requested content. When configuring a monitor, you typically set the expected status code to 200 for any standard web page.

However, a 200 response does not guarantee that the page content is correct. A web server might return a 200 status code but serve an error page, a Cloudflare challenge page, or an empty response body. This is why combining status code checks with content validation (keyword monitoring) provides much stronger coverage. If your monitor checks for both a 200 status code and the presence of your company name in the response body, it will catch scenarios where the server is technically "up" but not serving the correct content.

201 Created

Returned when a request has resulted in a new resource being created, most commonly in response to POST requests. In API monitoring, you might expect a 201 when testing endpoints that create resources. If your API monitoring test sends a POST request to create a test record and receives a 200 instead of the expected 201, that might indicate an API change worth investigating.

204 No Content

The server processed the request successfully but is not returning any content. This is standard for DELETE operations and certain API endpoints that perform actions without returning data. In monitoring, ensure your content validation is configured appropriately for endpoints that legitimately return 204 responses; a keyword check would obviously fail on an empty response body.

Monitoring Strategy for 2xx Codes

For most web pages, configure your monitors to expect a 200 response. For API endpoints, match the expected code to the endpoint's documented behaviour (200, 201, or 204 depending on the operation). Track response times alongside the status code, because a 200 response that takes 8 seconds to arrive is still a problem worth investigating. If response times for a URL gradually increase over days or weeks, that trend may indicate a developing infrastructure issue even though every individual check passes.

Redirection codes tell the client that the requested resource has moved and the client should make a new request to a different URL. Redirects are a normal part of web infrastructure, but they require careful monitoring to prevent performance issues and SEO problems.

301 Moved Permanently

The resource has permanently moved to a new URL. Search engines transfer the ranking signals (link equity) from the old URL to the new one. This is the correct redirect type for permanent URL changes, domain migrations, and HTTP-to-HTTPS transitions.

In monitoring, a 301 response is not inherently a problem. If you are monitoring http://example.com and it redirects to https://example.com with a 301, that is correct behaviour. Configure your monitor to either expect the 301 or to follow redirects and check the final destination. The important thing is that the redirect chain eventually terminates at a page returning 200.

302 Found (Temporary Redirect)

The resource has temporarily moved. Unlike a 301, search engines do not transfer ranking signals to the destination URL, because the move is considered temporary. In practice, 302s are frequently misused where 301s are appropriate. A monitoring alert for unexpected 302 responses can help you catch cases where a permanent redirect has been incorrectly configured as temporary, potentially leaking SEO value.

304 Not Modified

The resource has not changed since the client's last request. The server uses this code in conjunction with caching headers to tell the client it can use its cached version. You will occasionally see 304 responses in monitoring logs when the monitoring system supports conditional requests. A 304 is not an error; it is an optimisation.

307 Temporary Redirect and 308 Permanent Redirect

These are the HTTP/1.1 equivalents of 302 and 301, respectively, with the important distinction that they preserve the request method. A 301 or 302 can cause a POST request to be converted to a GET on redirect, whilst 307 and 308 guarantee the method is preserved. This matters for API monitoring where method preservation is critical.

Monitoring Strategy for 3xx Codes

Redirect monitoring focuses on three concerns:

• Chain length — Each redirect in a chain adds latency and consumes crawl budget. Flag redirect chains longer than two hops. A chain of http:// to https:// to www is three hops and should be consolidated into a single redirect from the source to the final destination.
• Redirect loops — When URL A redirects to URL B, which redirects back to URL A, the browser will eventually give up with an ERR_TOO_MANY_REDIRECTS error. Monitoring catches these loops immediately.
• Unexpected redirects — If a page that should return 200 suddenly starts returning a 301 or 302, something has changed. This might be intentional (a URL migration) or accidental (a misconfigured rewrite rule). Your monitor should alert on unexpected status code changes so you can verify the redirect is intentional.

Configure your monitors to follow redirects and validate the final destination, whilst also logging the complete redirect chain for analysis. This gives you both the "is the user getting to the right place?" answer and the "is the redirect path efficient?" insight.

The 4xx class indicates that the client's request was invalid or cannot be fulfilled. In monitoring, these codes often point to configuration issues, broken links, or access control problems.

400 Bad Request

The server could not understand the request due to malformed syntax. In web monitoring, a 400 response to a straightforward GET request usually indicates a server configuration issue rather than a genuine client error. If your monitor receives a 400 for a URL that should work, investigate whether the server is rejecting certain headers, query parameters, or character encodings.

401 Unauthorized

The request requires authentication. If you are monitoring a page that requires login, receiving a 401 is expected when the monitoring request does not include credentials. For public pages, a 401 response indicates that authentication has been accidentally enabled or a reverse proxy is misconfigured. For API monitoring, a 401 might indicate that your API key has expired or been rotated without updating the monitor configuration.

403 Forbidden

The server understood the request but refuses to authorise it. This is one of the most important codes for monitoring because it often indicates that a web application firewall (WAF), CDN, or security rule is blocking legitimate traffic. A 403 response that appears suddenly on a page that was previously accessible almost always warrants investigation.

In the context of SEO infrastructure, 403 responses are particularly dangerous when they are selective. A Cloudflare security rule might serve your pages correctly to human visitors (who pass the challenge) whilst blocking search engine crawlers with a 403. Your site appears to be working fine, but Googlebot cannot access your pages, and your organic rankings gradually deteriorate. This is exactly the scenario that differentiated monitoring approaches like bot-vs-browser comparison testing are designed to detect.

404 Not Found

The server cannot find the requested resource. 404 errors on monitored URLs indicate that a page has been removed or that the URL structure has changed without implementing proper redirects. A sudden spike in 404 responses across multiple URLs often points to a deployment error, a routing configuration change, or a CMS issue.

In monitoring, distinguish between expected and unexpected 404s. If you remove a page intentionally, update or remove the corresponding monitor. But if a page that should exist starts returning 404, that is an immediate failure requiring investigation.

405 Method Not Allowed

The HTTP method used in the request is not supported for the requested URL. You might encounter this in API monitoring if a GET request is sent to an endpoint that only accepts POST, or if your server's CORS configuration is rejecting preflight OPTIONS requests.

408 Request Timeout

The server timed out waiting for the request. In monitoring, this code is relatively uncommon because most monitoring systems have their own timeout settings that would trigger before the server's timeout. If you see 408 responses, your server may be under heavy load or the connection between the monitoring node and your server is experiencing significant latency.

429 Too Many Requests

The client has sent too many requests in a given time period. This rate-limiting response is important in monitoring for two reasons. First, your monitoring system itself might be triggering rate limits if check intervals are too aggressive, particularly if you have many monitors pointing at the same server. Second, and more critically in an SEO context, a 429 response served to search engine crawlers means your rate limiting is actively blocking search engines from indexing your content.

Monitoring Strategy for 4xx Codes

Every 4xx response on a monitored URL is potentially significant. Configure alerts for any status code change from the expected 200 to any 4xx code. Pay particular attention to 403 and 429 responses, which often indicate access control issues that affect search engine crawlers more than human visitors. For keyword monitoring, a 4xx response means the page content is entirely unavailable, which is always a failure state.

The 5xx class indicates that the server encountered an error whilst processing a valid request. These are the most urgent codes in monitoring because they represent failures in your own infrastructure.

500 Internal Server Error

A generic catch-all error indicating that the server encountered an unexpected condition. In a web application, this typically means an unhandled exception in your code: a database query that failed, a null reference in a template, or a missing configuration value. A 500 error on a monitored URL demands immediate investigation because it affects every visitor to that page.

The challenge with 500 errors is that the HTTP response alone does not tell you what went wrong. You need to check your application logs for the specific exception. Monitoring detects the symptom; your logging infrastructure provides the diagnosis.

502 Bad Gateway

The server, acting as a gateway or proxy, received an invalid response from an upstream server. In modern web architectures, 502 errors are extremely common because most deployments involve multiple layers: a CDN proxying to Nginx, Nginx proxying to Gunicorn, Gunicorn running your application. A 502 means one of those layers could not communicate with the next one.

Common causes include: the application server process has crashed or is not running, the upstream server is overloaded and dropping connections, or a deployment is in progress and the old process has stopped before the new one is ready to accept connections. In a CDN context, a 502 from Cloudflare means it could not reach your origin server.

503 Service Unavailable

The server is temporarily unable to handle the request, usually due to maintenance or overload. A well-configured application returns 503 during planned maintenance windows with a Retry-After header indicating when the service will be available again. In practice, 503 errors also occur during unplanned overload situations when the server runs out of worker processes, database connections, or memory.

For SEO, a 503 is actually the "correct" error to return during maintenance. Search engines treat 503 as a temporary condition and will retry later without penalising the page. Compare this to a 500 or a connection timeout, which search engines may interpret as a sign of unreliable infrastructure. If you must take your site offline, ensure your maintenance page returns 503, not 200 (which would cause search engines to index your maintenance page).

504 Gateway Timeout

The gateway or proxy server did not receive a timely response from the upstream server. This is similar to 502 but specifically indicates a timeout rather than an invalid response. In monitoring, 504 errors often correlate with periods of high load when your application server takes longer than the proxy's timeout to generate a response.

If you see intermittent 504 errors, check whether they correlate with specific times of day (peak traffic) or specific URLs (complex pages with expensive database queries). Persistent 504s on certain pages suggest those pages need performance optimisation.

Monitoring Strategy for 5xx Codes

All 5xx errors should trigger alerts. Unlike 4xx errors, which might indicate a configuration nuance, 5xx errors almost always represent genuine failures that affect real users. Configure your monitors with the following approach:

• 500 errors — Alert immediately. Investigate application logs for the underlying exception.
• 502 errors — Alert after 2 consecutive failures. A single 502 can occur during a deployment and resolve itself within seconds. Consecutive 502s indicate a persistent problem with your application server or proxy configuration.
• 503 errors — Alert after 2 consecutive failures unless you have a planned maintenance window scheduled, in which case suppress alerts for the duration.
• 504 errors — Alert after 2 consecutive failures. Investigate response times for the affected URL. If response times have been gradually increasing, the 504 is the culmination of a performance degradation trend that monitoring data should make visible.

Track the ratio of 5xx responses to total requests over time. A site that returns 5xx errors on 0.1% of checks has a very different profile from one that returns 5xx on 5% of checks. Trend analysis helps you distinguish between occasional transient errors and systemic reliability problems.

With a solid understanding of what each status code means, you can build a monitoring configuration that responds appropriately to different failure modes. Here is a practical framework for status-code-aware monitoring.

Baseline Expectations

For each monitored URL, define the expected status code. For most web pages, this is 200. For URLs that redirect, this might be 301 (if monitoring the original URL) or 200 (if following redirects and monitoring the destination). For API endpoints, match the expected code to the endpoint's specification. Any deviation from the expected code is a check failure.

Severity Classification

Not all status code changes are equally urgent. Use a tiered classification:

Status Code	Severity	Typical Action
200 (with slow response)	Warning	Investigate performance, check server resources
301/302 (unexpected)	Warning	Verify redirect is intentional, check SEO impact
403	High	Check WAF/CDN rules, verify crawler access
404	High	Check for URL changes, verify deployment
429	High	Review rate limiting rules, check crawler access
500	Critical	Check application logs immediately
502/503/504	Critical	Check server and proxy health, review resource usage
Connection timeout	Critical	Verify server is running and network is reachable

Response Time Correlation

Status codes and response times tell complementary stories. A page that returns 200 in 150 milliseconds is healthy. A page that returns 200 in 4 seconds is technically available but may be suffering from database slowness, memory pressure, or resource contention that could escalate to 5xx errors under increased load. Monitor response times alongside status codes and set warning thresholds at response times that exceed your normal baseline by a meaningful margin.

Historical Analysis

The real power of status code monitoring emerges over time. Weekly and monthly views of status code distribution reveal patterns:

• Are 5xx errors clustering at specific times of day? That suggests load-related issues.
• Are 403 errors appearing only for certain user agents? That points to overly aggressive security rules.
• Are redirect chains getting longer after deployments? That indicates accumulating URL changes without cleanup.
• Is the ratio of non-200 responses increasing gradually? That suggests a systemic issue that needs architectural attention.

Use your monitoring dashboard's historical data to identify these trends. Spotting a gradual increase in error rates early allows you to address the root cause before it becomes an outage.

Generic "site is down" alerts are a starting point, but status-code-specific alerting provides much richer operational intelligence. Here is how to configure alerts that tell you not just that something is wrong, but what kind of thing is wrong.

Configuring Code-Aware Monitors

In your website monitoring configuration, set the expected status code for each monitor. When the actual response differs from the expected code, the monitor records a failure. The alert message should include the actual status code received, because a 403 failure requires a very different response than a 502 failure.

If your monitoring platform supports it, configure different alert channels for different severity levels. Critical failures (5xx codes, connection timeouts) should trigger immediate notifications on all channels, including SMS for on-call personnel. Warning-level issues (unexpected redirects, slow responses) can be routed to email and Slack for review during business hours.

Building Runbooks by Status Code

Create a simple runbook that maps status codes to investigation steps. When an alert fires at 3am, the on-call engineer should be able to quickly determine what to check based on the status code:

• 403 received — Check CDN/WAF rules. Has a new security rule been deployed? Is the monitoring IP blocked? Check the same URL manually from a different network.
• 404 received — Check recent deployments. Has the URL structure changed? Was a rewrite rule modified? Check the CMS for published content at that URL.
• 500 received — Check application logs for the specific exception. Look for database connectivity issues, missing environment variables, or unhandled edge cases.
• 502 received — Check whether the application server process is running. Verify memory and CPU usage on the server. Check for recent deployments that might have crashed the application.
• 503 received — Check server load and resource usage. Is the server overwhelmed? Is a planned maintenance window in effect? Check for runaway processes consuming resources.
• 504 received — Check response times for the URL. Look for slow database queries or external API calls. Review proxy timeout configuration.
• Connection refused/timeout — Verify the server is running and reachable. Check DNS resolution. Verify firewall rules have not changed.

Integrating with Incident Management

For teams using incident management workflows, status code data enriches the incident record. When a critical alert fires, the monitoring system can automatically create an incident ticket with the status code, response time, affected URL, and the time the failure was first detected. This gives the response team immediate context without requiring them to log into the monitoring dashboard.

Pair your monitoring data with your API monitoring configuration to build a complete picture of both frontend and backend health. And for a broader view of how to construct a monitoring strategy from the ground up, read our complete guide to uptime monitoring.

If you are new to monitoring and want to get started quickly, our step-by-step setup tutorial walks through the entire process of creating monitors, configuring status code expectations, and setting up alerts in under five minutes.

HTTP status codes are the language your server uses to communicate its health. Learning to listen to that language, through systematic monitoring and thoughtful alerting, is one of the most effective things you can do to protect your website's reliability, performance, and search engine visibility.