This document describes the most common HTTP status codes that ObservePoint users will encounter.

Every time a web browser talks to a web server, it uses HTTP. HTTP is a protocol, or language, designed for the web. In HTTP, every interaction between a web browser and a web server is called a “request”. Every request has a response with a status code to tell the browser whether the request was successful, and if not, what went wrong.

The most common status codes are categorized into series:

This document describes the most common status codes in each series. ObservePoint has processed billions of HTTP requests. 99% of these requests ​​have one of the following status codes.

Any status code in the 200 range means that the server successfully handled the request from the browser. Even though there are some nuances in the meaning of the different 200 status codes, there is no material difference in the most common codes: 200, 201, 202, 204. Any time you see one of these status codes, it means the server successfully handled the request.

The 300 series of status codes mean that a redirect happened (except 304). There are technical differences between a 301 and 302 redirect, but for most people, these both have the same effect: the server told the browser to go to a different URL to get the page or network request the browser requested.

Status codes in the 300 range are server-side redirects, as opposed to client-side redirects. Client-side redirects are done by the browser with JavaScript code or HTML <meta> tags. There is no difference to the end result between server-side and client-side redirects: the browser ends up at the new location.

Note that on-page requests like analytics events can also follow redirects, but only server-side redirects apply in this context, since there is no HTML or JavaScript involved in the response of an on-page request.

Redirects are usually fast, less than one second. Less than one second may seem fast, but if a redirect chain has, say, ten redirects, users may abandon the process by navigating away from the page. For this reason, most websites try hard to minimize the number of redirects that browsers must follow. ObservePoint reports this at the page level, and you can set up an alert to notify you if any of your pages follow too many redirects.

Common Redirect Status Codes: 301, 302, 303, 307, 308

These status codes are different ways of doing server-side redirects. The differences between these status codes matter to developers–especially developers who create web browsers–but they all have the same result: the browser redirects to a different URL.

304: Not Modified: For Caching

The 304 status code is not the same as the other redirect status codes. A server sends a 304 to the browser for caching purposes. When the server determines it does not need to send a file back to the browser, because the browser already has an up-to-date version of the file, the server can send a 304. In other words, a 304 is how the server tells the browser “go ahead and use the file you already have, and I’ll save costs by not sending it to you again”. This is very useful for caching large content like images.

This category of error means that the server thinks that the browser (or code running on the browser) made a mistake, and requested something it should not have.

Web servers can send these status codes for many reasons, ranging from permissions to throttling. This section describes the most common errors in the 400 range.

400: Bad Request

This is the most common, and most generic, status code in the 400 range. It means the server refused to handle the request for many potential reasons. These reasons can range from malformed URLs to bad query string values to site-specific errors. The 400 status code is very common for errors, and often you can find more detail about why the server rejected the request in response headers or the response body. Many websites don’t get more specific than 400, and even though a more specific status code exists (e.g., 429) for a given situation, the website may return 400 anyway.

401: Unauthorized

This error means that the user is not logged in when trying to make this request. If you see this error, one possible solution is to add pre-audit actions or web journey actions to log the browser in. However, this is not the only way to solve it 100% of the time.

Many websites use this error code incorrectly, mistaking it for a 403 error.

403: Forbidden

403 is also a common error code. It means that the user is not allowed to perform the attempted request or access the requested page. There are many reasons that a server can deny a user from performing an action. According to the HTTP specification, one of these reasons is not that the user isn’t logged in. The 403 status is also used when a certain browser or client has been blocked, for example, because the server thought the client was a bot or because the browser is requesting pages too fast. If this happens in an ObservePoint audit, you’ll need to add ObservePoint’s IP addresses to your vendor’s allowlist to bypass bot detection and rate limiting (for more on rate limiting, see 429 below).

404: Not Found

This is the most well known HTTP error code. It means that the server could not find the URL that the browser requested.

429: Too Mant Requests

This means the server throttled the request. For ObservePoint users, this usually happens in response to an audit or journey that requested too many pages too quickly for your website. Many websites use content distribution networks like Akamai or CloudFlare to limit the number of requests that a browser can make over a certain time period. This is called “rate limiting” or “throttling”, and it’s designed to prevent bad actors from sending so much traffic to your website that the website stops working for other users (this is called a “denial of service attack”). If your CDN rate limits ObservePoint, you’ll need to either reduce the speed that ObservePoint audits your site or add ObservePoint’s IP addresses to your vendor’s allowlist to bypass rate limiting.

You can reduce the speed that ObservePoint audits your site by:

The 500 series tells the browser that something went wrong on the server side. There are many reasons this can happen, ranging from an outage to a server misconfiguration, but there’s typically nothing the user can do about this. This requires the website owner to get involved and fix the problem. The 500 series errors have technical differences, but most of them describe the same kind of problem: something seriously bad happened on the server side.

500, 502, 503, 504: Server Errors

These status codes mean something bad happened on the server side. There is nothing the browser can do to fix it. While there are important differences between these status codes for developers, they all mean the server could not complete the request due to a problem that was not caused by the browser.

Many times (especially for 502, 503, and 504), this problem will be resolved if the browser retries later. But be careful not to retry too quickly, or you might make the problem worse.

The 504 status code is a special kind of failure: it means the server took too long to execute the request. When you see this status code, be a good web citizen, and do not retry, because the request that 504’ed probably consumed a lot of CPU on the server side, which can get expensive for the website owner and slow down other users of the web server.

501: Not Implemented

This error code is different from the others in the 500 series. This means that the server can’t handle the request because it was not built to do so. It’s rare to happen, but what you need to know is that retrying won’t fix it.