HTTP Status Codes Explained: The Complete Reference

What Are HTTP Status Codes?

When your browser requests a webpage, or when an uptime monitor checks your URL, the server responds with a three-digit HTTP status code. This code tells the client (browser, monitor, API consumer) what happened with the request.

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

Class	Range	Meaning
1xx	100–199	Informational
2xx	200–299	Success
3xx	300–399	Redirection
4xx	400–499	Client Error
5xx	500–599	Server Error

For uptime monitoring, the most important classes are 2xx (everything is working) and 4xx/5xx (something is wrong).

2xx — Success Codes

200 OK

The standard success response. The request was received, understood, and processed. This is what you want your uptime monitor to see.

201 Created

The request was successful and a new resource was created. Common response for POST requests to REST APIs.

204 No Content

The request was successful but there's no content to return. Common for DELETE requests and API health checks that just need to confirm availability.

3xx — Redirection Codes

301 Moved Permanently

The URL has permanently moved to a new location. Browsers and search engines update their records. Your monitor should follow this redirect.

Monitoring tip: If your monitor sees a 301, update your monitored URL to the new destination. Monitoring a redirect chain adds latency.

302 Found (Temporary Redirect)

The URL has temporarily moved. Browsers redirect, but search engines don't update their records. Common for login redirects.

304 Not Modified

The resource hasn't changed since the last request (used with caching headers). Not a failure — but unusual to see in monitoring responses.

4xx — Client Error Codes

These indicate the problem is with the request itself (the URL, credentials, or permissions).

400 Bad Request

The server couldn't understand the request due to malformed syntax. For monitoring, this usually means the URL or request headers are malformed.

401 Unauthorized

Authentication is required and wasn't provided (or failed). If your monitor sees 401, the URL may require authentication that you need to configure.

403 Forbidden

The server understood the request but refuses to authorize it. The difference from 401: no amount of authentication will help — the resource is simply not accessible to this client.

Monitoring alert: If your public homepage returns 403, your server may have blocked the monitoring service's IP range. Whitelist the monitoring IPs.

404 Not Found

The requested URL doesn't exist on the server.

Common causes in monitoring:
- The page was deleted or moved
- A typo in the monitored URL
- The server is partially down (database disconnected but web server running)

429 Too Many Requests

The client has sent too many requests in a given time window (rate limiting). If your monitor triggers 429, reduce the check frequency.

5xx — Server Error Codes

These indicate the server encountered an error processing the request. These are the codes your uptime monitor cares most about.

500 Internal Server Error

The most common server error. Something went wrong on the server — a crashed application, database error, or unhandled exception.

Action required: Check your application logs immediately.

502 Bad Gateway

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

Common causes:
- Your application server (Node.js, Python, PHP-FPM) crashed
- Your reverse proxy (Nginx, Caddy) can't reach the app server
- Memory exhaustion on the application server

503 Service Unavailable

The server is temporarily unable to handle requests — usually due to overload or maintenance.

Monitoring tip: Some sites return 503 during planned maintenance. You can configure your monitor to expect this code during maintenance windows to avoid false alerts.

504 Gateway Timeout

The gateway didn't receive a timely response from the upstream server. Similar to 502, but specifically a timeout.

Common causes:
- Slow database queries blocking request completion
- Upstream microservice taking too long
- Network issues between servers

521, 522, 523, 524 (Cloudflare-specific)

If you're behind Cloudflare, you may see these proprietary codes:
- 521: Web server is down (Cloudflare can reach the origin but it refuses connections)
- 522: Connection timed out
- 523: Origin unreachable
- 524: A timeout occurred (request reached origin but took too long)

What Status Code Should My Monitor Expect?

By default, uptime monitors expect 200 OK. But some URLs legitimately return other codes:

URL Type	Expected Code
Standard webpage	200
API health endpoint	200 or 204
Redirect (www → non-www)	301 (monitor the destination)
Protected page (login required)	200 or 302 to login
API with authentication	401 (if not authenticated)

In ismysiteup, you can set the expected status code per monitor. This lets you correctly monitor redirects, health endpoints that return 204, and other non-standard responses.

How Status Codes Affect SEO

Code	SEO Impact
200	No impact — healthy
301	Passes ~99% of link equity to new URL
302	Doesn't pass link equity — use 301 for permanent moves
404	Page removed from index over time
500/503	Page temporarily removed from index; may recover
Consistent 5xx	Significant negative impact on crawl frequency and rankings

Conclusion

HTTP status codes are the language your server uses to communicate its health. Understanding them makes you a more effective developer, sysadmin, and website owner — and helps you configure your uptime monitors correctly so you catch real problems and avoid false alerts.

Set your expected status code correctly in ismysiteup and you'll never miss a real outage again.