HTTP Status Codes: The Complete Guide for Website Monitoring

It’s 5:00 on a shoot day. A gaffer on a film crew wants to confirm their gear reservation with Griphouse, a local film equipment rental company. But instead of receiving a simple reservation confirmation, they’ve hit an error screen displaying some number. The shoot begins in an hour.

This experience is suboptimal for the gaffer, certainly, but Griphouse knows about the issue because they are monitoring their website. The number tells them exactly where to start looking for what went wrong.

Every HTTP request receives a status code sent in the header, which provides diagnostic information for developers and site owners. This guide covers what all the main status codes mean, illustrated with concrete scenarios, so that by the end, you will know why monitoring those codes matters for your site. You can use this guide and the cheat sheet at the bottom as a reference to quickly look up the significance of the most common HTTP status codes you are likely to encounter.

Looking for a specific code? Jump to the Quick-Reference Table.

What Are HTTP Status Codes?

HTTP status codes are 3-digit codes that a web server sends back with every HTTP response, alongside the page content. The first digit in the code indicates the category of the response (success, error, redirect, etc.).

When a production company loads a Griphouse page, their browser sends an HTTP request and the Griphouse server responds with the page content and a status code. Most users won’t directly see that status code; they will just see the result of it, whether it’s the page loading normally or an error page.

The status codes travel in the response header — a block of metadata sent with the HTTP message — which developers can observe in the browser DevTools. Monitoring tools like Testomato enable you to set expected status codes per page URL and alert you when a different code is received.

The 5 Categories

All HTTP response status codes are grouped into one of five classes, which are indicated by their first digit.

Note: 1xx informational codes are protocol-level, interim responses sent during a request. They are rarely encountered in day-to-day monitoring or debugging.

2xx — Success

A 2xx code means that the request was successful. The specific code gives you more information about what kind of success.

200 OK

200 is the standard success response. The server found the requested resource and returned it.

Griphouse’s rental booking confirmation page loads, the customer sees their order, and the revenue is captured.

For monitoring, 200 is the code that you assert on almost every critical URL. When adding a new website project in Testomato, the preset checks include an HTTP Status Code = 200 check for the top eight links found on your homepage, plus the favicon, robots.txt, and 404 page.

201 Created

The server successfully created a new resource as a result of the request. This status code is typically sent as the result of a POST request.

For example, on the Griphouse website, a new rental order record is written to the database.

This code is common in REST APIs and less common on customer-facing page loads, so it is rarely something you’d need to directly monitor.

204 No Content

The request succeeded but the server has nothing to return in the response body and the client (browser) doesn’t need to navigate away from the current page.

A production company removes a camera cage from their cart. The cart update completes successfully but there’s no new page to render.

This is a common response for update and delete API calls.

3xx — Redirects

3xx codes tell the client that some additional navigation is required in order to retrieve the requested resource. Generally this action is a URL redirection. The specific code will indicate whether the redirection is permanent or temporary, which impacts how browsers cache the redirect and whether they preserve or transfer SEO equity from the original URL to the new one.

301 Moved Permanently

The resource has permanently moved to a new URL. Browsers and search engines update their records.

After refreshing their camera catalog, Griphouse restructures their listing URLs. Old product pages redirect with status 301 to the new ones. Search engines transfer the ranking equity to the new URLs and bookmarks start working again after one visit.

An unexpected 301 on a page you expect to return 200 can signal a misconfiguration in your redirects. Testomato follows redirects by default, but to specifically assert the 301 code itself, you can disable “Follow redirects” on the check. You can also add a Redirect Location check to verify that the old URL redirects to the correct destination URL.

302 Found

The resource is temporarily located at a different URL. The original address remains valid, so browsers won’t update bookmarks and search engines continue to index the original URL.

During a scheduled maintenance window, the Griphouse booking form redirects temporarily to a status page. The original URL stays intact.

Just like with 301, Testomato follows 302 redirects by default. Disable “Follow redirects” to assert the 302 code itself, or add a Redirect Location check to verify the temporary destination is correct. If the move is meant to be permanent, change it to 301 to preserve your SEO equity.

304 Not Modified

Technically a 3xx redirection response status code, but it indicates a cache hit. The server is telling the browser that it found no changes in the requested resource since it was last cached. The browser will retrieve the cached version of the page and no content is sent.

A returning Griphouse customer browses the camera lens catalog that they visited last week. Their browser has already cached the images from the Griphouse CDN and the server confirms that nothing has changed; images load quickly without re-downloading.

You typically won’t assert a 304 in your status code checks, but it’s good to be aware of it since you may see 304s in DevTools when a browser checks if a cached resource is still up to date.

307 (Temporary Redirect) and 308 (Permanent Redirect)

These two status codes correspond to 302 and 301 respectively, but they preserve the HTTP method (POST, PUT, etc.) used in the original request across the redirect. By contrast, with 301/302 browsers may convert a POST to GET. This can, for example, cause form data to be lost. But with 307/308 the request method cannot be altered. Most sites won’t encounter 307/308 in day-to-day monitoring; they matter mainly when redirecting endpoints that accept POST/PUT requests, like form submissions or API calls.

4xx — Client Errors

4xx codes mean that there is a problem with the request, not the server. The server understood the request but couldn’t or wouldn’t process it.

400 Bad Request

The server can’t process the client’s request because it is malformed or contains invalid data.

A Griphouse customer submits a rental date range with a return date that is before the pickup date. The booking API can’t parse the request and returns 400. The customer sees an error and either corrects the input mistake or calls support.

Some common causes of the 400 Bad Request response code include: malformed request syntax (e.g., invalid JSON or unescaped characters) or invalid/missing parameters (e.g., required fields missing or incorrect data types).

401 Unauthorized

The request requires valid authentication credentials in order to receive the requested resource from the server. Frequently, the user either hasn’t logged in or their session has expired and they must reauthenticate. The client should authenticate and try the request again.

The gaffer checks their order history at 5:00 on the shoot day. Their session expired overnight and when they reopen their browser tab they hit a 401 and have to log in again.

If your monitoring tool detects 401s on a page that should be publicly accessible, it is worth investigating; a broken session cookie or misconfigured authentication middleware can cause problems for more than just one user. For authenticated pages, a 401 is expected when a session expires, so it’s less useful to monitor directly.

403 Forbidden

The server understood the request and the user may be authenticated but access is refused. Unlike 401, re-authenticating won’t make a difference because the server is intentionally refusing to process the request, usually because the client does not have sufficient permissions.

The gaffer is logged into Griphouse and pastes a direct URL to an order sent by a colleague. The server returns 403 because it knows who they are, but it won’t let them see someone else’s order.

An unexpected 403 on a page that should be publicly accessible tells you that something is blocking access that shouldn’t be.

404 Not Found

The server can’t find the requested resource. It may have been moved, deleted, or the URL may simply be wrong. Links leading to a 404 page are often referred to as “broken” or “dead” links.

A discontinued camera model was formerly available for rent on Griphouse and is still linked from a two-year-old blog post. The product detail page for that old model has been deleted, but visitors using the popular blog link hit the 404.

Without monitoring, a deleted or broken page can sit returning 404 indefinitely before anyone notices.

410 Gone

The resource existed but has been removed. It is a stronger signal than 404, which could mean “not found for any reason,” whereas 410 explicitly indicates it is “gone” on purpose.

For a second discontinued camera model, Griphouse deliberately removes the product detail page and returns 410 so that Google will deindex it faster to prevent stale content from appearing in search results and wasting crawl budget.

If you expect a URL to be gone there is no need to monitor it, but an unexpected 410 on a live page is worth alerting on. Repeated 410s suggest there is an accessible or linked URL that should be completely removed or replaced.

429 Too Many Requests

The client has sent too many requests in a given time window and is being rate-limited. The server may include a “Retry-After” header in the response to tell the client how long to wait before making the request again.

Griphouse announces a flash sale on social media. During the sale window, the site traffic spikes, payment API calls surge, and rate-limiting kicks in.

A spike in 429s tells you that a rate limit was hit; either a traffic surge overwhelming your server or a third-party API integration, like a payment processor or authentication service.

5xx — Server Errors

5xx codes mean that something went wrong on the server. The request was valid but for some reason the server couldn’t handle it. Unlike 4xx errors, the visitor can’t do anything to fix them.

500 Internal Server Error

500 is a generic server error response code indicating that something went wrong but the server cannot find a more specific 5xx code to respond with.

A database error occurs during the rental availability calculation and the checkout page crashes. The transaction is never completed.

Seeing 500 errors on a page is high urgency for site owners and administrators. The code itself provides very little info about the cause, and there are many possible causes of 500 errors (e.g., unhandled exceptions from failed database queries), which require further investigation.

502 Bad Gateway

The server acting as a gateway or proxy received an invalid response from an upstream server.

Griphouse’s Nginx proxy can’t reach the Nuxt app server behind it because the app crashed after a bad deploy. Every page request returns 502 and the site is down until the app server is restarted.

502s can be intermittent and easy to miss without monitoring because they may resolve before anyone notices.

503 Service Unavailable

The server is temporarily unable to handle requests, often because it is overloaded or intentionally down for maintenance.

Griphouse schedules maintenance to deploy a new catalog feature overnight. They bring the server down and return 503 with a Retry-After header, providing an estimate of when the service should be available again to process requests.

If the 503 is not expected, there is an urgent issue to resolve because it indicates your site is completely unavailable to visitors. For planned outages, configure your monitoring tool to expect the downtime and avoid triggering alerts during that window.

504 Gateway Timeout

A gateway or proxy server didn’t receive a response from an upstream server in time to complete the request. This is similar to a 502 Bad Gateway, but instead of an invalid response from the origin, the proxy or gateway did not receive any response.

A Griphouse customer requests a quote for a complex multi-option rental package. The inventory database query runs long and the gateway gives up waiting. As a result, the customer sees a timeout error and abandons the cart.

504s, like 502s, are often intermittent and can occur during periods of server overload or when an upstream service is experiencing degraded performance. It’s possible for a 504 to resolve before a standard uptime check catches it, since the check itself might time out and retry rather than recording the 504. For this reason, it’s worth watching your response time data alongside status codes.

The Soft 404 Problem

A “soft 404” is when a server returns a 200 OK response for a page that should actually return 404. A page that has no useful content for users — “product not found,” “item no longer available” — but returns 200, telling crawlers that it’s a valid page worth indexing. In other cases a soft 404 may occur when a server returns 200 for non-existent pages.

The Griphouse page for a discontinued camera model was left live, showing “this item is no longer available.” The server returns 200, so Google keeps indexing the page, wasting the crawl budget and leading customers to a dead end.

Adding keyword and content checks when monitoring your pages enables you to catch what HTTP status code monitoring alone misses. If a page returns 200 but the expected heading, item quantity, or product name is gone, something is wrong. Testomato also automatically adds a 404 check on new projects to verify the server correctly returns 404 for non-existent pages.

Why HTTP Status Code Monitoring Matters

A status code change on any URL won’t produce an alert unless you are monitoring your pages and asserting the codes that you expect. If uptime monitoring is the first and most basic monitoring principle for your site as a whole, then asserting 200 OK on all your main pages is the fundamental check at the page level. Always monitor the status codes on critical pages: homepage, checkout flows, booking/contact forms, static asset CDNs, and key API endpoints.

You can supplement your core 200 OK checks with keyword and metadata checks to ensure every page is rendering the correct content. You may also want to add checks for other expected codes, like 301/302 redirects and the 404 page for non-existent pages. With your expected status codes set per URL, you’ll get alerted whenever a deviation is detected.

Start Monitoring Your Website →

Quick-Reference Table

Cheat Sheet

A one-page reference covering the codes that matter most for monitoring, with a tip for each one. Open it in your browser or save it as a PDF.

Open the HTTP Status Codes Cheat Sheet

Resources

MDN HTTP Status Codes — comprehensive developer reference with full descriptions and browser compatibility notes

IANA HTTP Status Code Registry — the authoritative list of all registered status codes

httpco.de — a tool for triggering specific HTTP status codes on demand; useful for testing how your monitoring tool responds to different codes