HTTP Status Codes Explained

HTTP Status Codes Explained

Every HTTP response includes a three-digit status code. It tells the client - a browser, an API consumer, a monitoring tool - what happened with the request. The first digit defines the category. The remaining two digits define the specific result within that category.

There are five categories:

• 2xx - Success. The request was received, understood, and processed.
• 3xx - Redirection. The client needs to take another action to complete the request.
• 4xx - Client error. The request was invalid or unauthorized.
• 5xx - Server error. The server failed to fulfill a valid request.

This guide covers the codes you will encounter in production, what they mean, and how to catch them before your users do.

---

2xx - Success

200 OK

The standard success response. The request worked, and the server is returning the requested content. For a GET request, the response body contains the resource. For a POST, it contains the result.

200 is what your uptime monitor expects to see. If your homepage returns anything other than 200, something is wrong.

201 Created

The request succeeded and a new resource was created as a result. Common response to POST requests in REST APIs - when a user signs up, a record is created, or a file is uploaded. APIs that create resources should return 201, not 200.

204 No Content

The request succeeded but there is no content to return. Used for DELETE requests or actions where the server has nothing meaningful to send back. The response has no body.

206 Partial Content

The server is delivering only part of the resource, in response to a range request from the client. Used for resumable downloads, video streaming, and large file transfers.

---

3xx - Redirection

301 Moved Permanently

The resource has been permanently moved to a new URL, included in the Location header. Browsers and search engines cache this redirect and update their records. All future requests go to the new URL.

Use 301 when you rename a URL permanently - migrating from HTTP to HTTPS, restructuring routes, or moving a domain. Search engines transfer link equity to the new URL.

302 Found

Temporary redirect. The resource is available at a different URL for now, but the original URL remains valid. Browsers follow the redirect but do not cache it. Search engines keep the original URL indexed.

Misusing 302 when you mean 301 is a common mistake. If the move is permanent, use 301.

304 Not Modified

The client sent a conditional request (with If-Modified-Since or If-None-Match), and the server confirms the cached version is still valid. No content is sent. The browser uses its cache.

This is normal, expected behavior for static assets. It reduces bandwidth and speeds up page loads.

307 Temporary Redirect / 308 Permanent Redirect

Stricter versions of 302 and 301. The key difference: the HTTP method must not change. A POST to a URL that returns 307 must be followed as a POST to the new URL, not converted to a GET. Use these when method preservation matters - typically in API flows.

---

4xx - Client Errors

400 Bad Request

The server cannot process the request because something is wrong with it. Malformed JSON, missing required parameters, invalid field values. The client sent something the server cannot understand.

In API monitoring, a spike in 400s usually means a client-side change broke the request format - a frontend deployment that changed a payload structure, or an integration that started sending unexpected data.

401 Unauthorized

The request requires authentication and none was provided, or the credentials are invalid. The client should authenticate and retry.

Do not confuse with 403. A 401 means "I do not know who you are." A 403 means "I know who you are, and you cannot do this."

403 Forbidden

The server understood the request and knows who the client is, but refuses to authorize it. The user does not have permission for this resource.

Common causes: accessing an admin route without admin rights, a misconfigured IAM policy on a cloud storage bucket, or an IP-restricted endpoint receiving a request from an unexpected source.

404 Not Found

The server cannot find the resource at the requested URL. Either the URL never existed, or it existed and was removed without a redirect.

404 is the most user-visible error on the web. For a monitoring tool, an unexpected 404 on a previously working URL is a clear signal: something was deployed incorrectly, a route was removed, or a DNS change pointed traffic to the wrong place.

If your homepage or API root suddenly returns 404, your service is effectively down for anyone trying to reach it.

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 indicating when to try again.

From a monitoring perspective, a 429 on your own service means something is hammering your API - a misconfigured client, a runaway background job, or a spike in legitimate traffic your rate limits were not calibrated for.

499 Client Closed Request

Not an official HTTP standard, but widely used in Nginx logs. The client disconnected before the server finished responding. Common during slow API responses - the user or the upstream service gave up waiting.

A spike in 499s is a signal that your response times have crossed a threshold users or integrations are not willing to wait for.

---

5xx - Server Errors

500 Internal Server Error

The generic server error. Something went wrong on the server that does not fit a more specific code. An unhandled exception, a crash, a misconfigured environment variable, a database query that returned an unexpected result.

500 is the code uptime monitors watch most closely. A 500 on your homepage means your application is broken. A 500 on an API endpoint means integrations are failing silently until someone notices.

502 Bad Gateway

A server acting as a gateway or proxy received an invalid response from an upstream server. Common in architectures where Nginx or a load balancer sits in front of your application server. The reverse proxy is reachable, but the app server behind it is not responding correctly.

502 often appears during deployments when the old application process has been stopped but the new one has not started yet.

503 Service Unavailable

The server is temporarily unable to handle the request. The most common causes are the server being overloaded (too many concurrent requests) or down for maintenance.

503 is the right code to return when you take your application offline intentionally - maintenance mode, deployment downtime, or capacity limits reached. Well-behaved clients treat 503 as temporary and retry after the Retry-After delay if provided.

From a monitoring perspective, 503 is serious. It means your service is refusing traffic. An alert should fire immediately.

504 Gateway Timeout

The gateway or proxy did not receive a timely response from the upstream server. Similar to 502, but specifically a timeout rather than an invalid response.

504s often surface under high load or when a database query hangs. The request reached your infrastructure but something upstream took too long to respond and the gateway gave up.

521, 522, 523, 524

Not standard HTTP, but Cloudflare-specific codes you will encounter if your infrastructure sits behind Cloudflare:

• 521 - The origin server refused the connection.
• 522 - Connection timed out.
• 523 - Origin is unreachable.
• 524 - A timeout occurred.

These behave like 5xx errors for monitoring purposes. If your monitor starts seeing 52x codes, Cloudflare is reachable but your origin server is not.

---

How uptime monitoring uses status codes

An uptime monitor sends HTTP requests to your endpoints and evaluates the response. The most basic check: did the response match the expected status code?

By default, most monitors treat 2xx responses as passing and anything else as a failure. But the right configuration depends on your endpoint:

• A login redirect might return 302 - you want to check for 302, not 200.
• An authenticated endpoint returns 401 if called without credentials - your monitor needs to include the right auth headers to get a 200.
• A health check endpoint might return 204 - configure your monitor to accept 204 as a pass.

Beyond status codes, a good monitor also checks response body content. A server can return 200 with an error message in the body - a PHP fatal error on a page that still loads the header, or an API that returns {"status": "error"} with a 200 code. Body keyword checks catch these.

Nodown's monitoring evaluates both. You define the expected status code and, optionally, a string that must appear in the response body. If either condition fails, the check fails. If checks fail across at least three of Nodown's 14 monitoring regions, an alert fires through your configured alert channels - Slack, Discord, PagerDuty, SMS, or webhook.

That multi-region confirmation step matters. A single-region failure is often a network blip between the monitoring server and your endpoint. A failure confirmed from three separate regions means your service is actually down.

You can also configure per-check alert thresholds - alert only after two consecutive failures, or alert immediately on the first failure for critical endpoints. For a payment API, you want to know the moment a 500 appears. For a documentation site, waiting for two failures before alerting reduces noise.

Start monitoring your endpoints free on Nodown

---

Quick reference

Code	Name	What it means
200	OK	Request succeeded
201	Created	Resource created
204	No Content	Success, no body
301	Moved Permanently	Permanent redirect, cache it
302	Found	Temporary redirect
304	Not Modified	Use cached version
400	Bad Request	Malformed request
401	Unauthorized	Authentication required
403	Forbidden	Authenticated but not authorized
404	Not Found	URL does not exist
429	Too Many Requests	Rate limit exceeded
500	Internal Server Error	Generic server failure
502	Bad Gateway	Invalid upstream response
503	Service Unavailable	Server overloaded or in maintenance
504	Gateway Timeout	Upstream response timed out

---

Last updated: May 2026.