The Complete Guide to HTTP Status Codes for Monitoring
HTTP status codes tell your monitoring tool what happened when it checked your URL. Knowing what each code means — and whether it should trigger an alert — is fundamental to setting up monitoring that actually works.
When PingBase checks your URL, it makes an HTTP request and reads the response status code. That three-digit number determines whether your monitor is "up" or "down." But the right interpretation depends on the context: a 301 is fine for a homepage redirect, problematic for an API endpoint. A 401 means something different on a public page versus an authenticated API. A 429 is a problem you caused yourself.
This guide covers every status code class you'll encounter in monitoring, what each means in practice, and how to configure your monitors correctly.
2xx — Success: the codes you want to see
200 OK
The request succeeded and the server returned a response body. This is what most monitors look for. A 200 from your homepage, API endpoint, or health check means the service is reachable and responding correctly.
Monitoring config: accept 200. Consider also checking response body content — a 200 that returns an error page ("Something went wrong") is technically a success code but indicates a problem.
201 Created
The request succeeded and a new resource was created. Returned by POST endpoints after successful creation. Most monitoring tools won't see this in a standard GET check, but if you're using POST monitors for webhook verification or API health checks, you might.
Monitoring config: accept 201 for POST monitors that create resources.
204 No Content
The request succeeded but there's no response body. Common for DELETE requests and some health check endpoints that intentionally return empty responses. PingBase counts 204 as "up" by default.
Monitoring config: accept 204 — it's a valid success response.
3xx — Redirects: usually fine, sometimes not
301 Moved Permanently
The URL has permanently moved to a new location. Common for HTTP → HTTPS redirects (http://yoursite.com → https://yoursite.com) and www → non-www or vice versa.
Monitoring config: PingBase follows redirects by default and counts the final destination's status code. Best practice: update your monitor URL to the final destination so you're monitoring the actual endpoint, not the redirect chain. A 301 can mask a broken destination.
302 Found (Temporary Redirect)
The resource is temporarily at a different URL. Often used for login redirects — if your app redirects unauthenticated requests to a login page, your monitor will see a 302 unless you send an auth header.
Monitoring config: if you're monitoring an authenticated endpoint and seeing 302, configure your monitor with the appropriate Authorization header, or add a health check endpoint that doesn't require auth.
304 Not Modified
The cached version is still valid — no new content. Rare in monitoring contexts since monitoring tools don't usually maintain HTTP caches, but can appear with conditional GET requests.
4xx — Client errors: usually a configuration problem
4xx errors mean the server received the request but refused or couldn't fulfill it. These almost always indicate a monitoring configuration issue rather than a server problem — though not always.
400 Bad Request
The server couldn't parse the request. Usually means the monitor is sending malformed headers or an invalid request body.
Monitoring config: check your custom headers and request body format. A 400 from a health check endpoint usually means your POST body isn't valid JSON, or a required header is missing.
401 Unauthorized
Authentication required (or failed). Your monitor is hitting an endpoint that requires credentials.
Monitoring config: add an Authorization header to your monitor, or create a dedicated unauthenticated health check endpoint at /health or /api/ping. Don't expose credentials unnecessarily — use a purpose-built health check.
403 Forbidden
The server understood the request but refuses to authorize it. This differs from 401: the server knows who you are (or that you're unauthenticated) and explicitly denies access. Common causes: IP allowlisting, geographic restrictions, or Cloudflare/WAF rules blocking the monitoring probe.
Monitoring config: if monitoring probes are being blocked by your WAF or firewall, either whitelist PingBase's probe IP ranges, or use a health check endpoint that's explicitly allowed through. A 403 from your public homepage is worth investigating — it may mean your Cloudflare settings are too aggressive.
404 Not Found
The URL doesn't exist. For monitoring purposes: you're probably monitoring the wrong URL, or the URL changed without updating your monitor.
Monitoring config: alert on 404. Update your monitor URL if the endpoint moved. Note: some apps return 404 for API routes that don't match — your health check endpoint might not exist yet. Create it.
429 Too Many Requests
Your monitoring tool is being rate-limited. This is a problem you created: your check frequency is too high, or your monitoring probe IPs have hit a rate limit shared with other users.
Monitoring config: reduce check frequency, or configure your health check endpoint to be exempt from rate limiting (it should be — health check endpoints typically don't need rate limiting since they're not user-facing). A 429 appearing on your monitor is worth alerting on — it means something is blocking your visibility.
499 Client Closed Request (Nginx)
Not an official HTTP status code, but Nginx logs 499 when the client disconnects before the server finishes responding. In monitoring contexts, this usually means your monitor's timeout was exceeded and it closed the connection.
Monitoring config: increase your monitor timeout, or investigate why the endpoint is slow to respond.
5xx — Server errors: alert on these
5xx errors mean the server received the request but something went wrong on its end. These should always trigger alerts.
500 Internal Server Error
The server crashed or encountered an unhandled exception. This is the catch-all server error — "something went wrong and the server doesn't have a more specific code for it." Almost always indicates an application bug, unhandled exception, or infrastructure failure.
Alert severity: high. A 500 on your main URL means users are seeing errors. Investigate immediately.
502 Bad Gateway
A proxy or gateway (Nginx, load balancer, Cloudflare) received an invalid response from the upstream server. Usually means your application server is down or returning garbage — the proxy is working, but what it's proxying to isn't.
Alert severity: high. Often the first sign that your application process has crashed or restarted.
503 Service Unavailable
The server is temporarily unable to handle requests — overloaded or in maintenance mode. This is also the code typically returned during deployment (if your deploy takes your app offline) and by maintenance pages.
Alert severity: high for unexpected 503s. If you're doing planned maintenance, use PingBase scheduled maintenance windows to suppress the alert and prevent it from showing as downtime on your status page.
504 Gateway Timeout
The proxy/gateway didn't get a timely response from the upstream. Your application is alive enough to receive the request but too slow to respond within the timeout.
Alert severity: high. Often indicates database query timeouts, connection pool exhaustion, or a CPU-bound operation hanging. Users are seeing timeouts.
Timeouts: not a status code, but critical
A timeout is not an HTTP status code — it's what happens when there's no response at all within the configured time limit. Your monitoring tool sends a request; the server doesn't respond within N seconds; the check is marked as failed.
Timeouts can mean:
- The server is completely unreachable (network outage, server down)
- The server is so overloaded it can't accept new connections
- A firewall is dropping packets rather than refusing connections
- Your timeout threshold is too short for a slow but functional endpoint
PingBase's default check timeout is 30 seconds. For most web applications, anything taking more than 5-10 seconds is already a user-facing performance problem. You can adjust the timeout per monitor — shorter for APIs where latency matters, longer for endpoints that do heavy processing.
Quick reference: status codes and monitoring action
| Code | Meaning | Alert? | Action |
|---|---|---|---|
| 200 | OK | No — up | Expected success |
| 301/302 | Redirect | Follow redirect | Update monitor URL to final destination |
| 401 | Unauthorized | Yes | Add auth header or use health check endpoint |
| 403 | Forbidden | Yes | Check WAF/firewall rules blocking probe IPs |
| 404 | Not Found | Yes | Verify URL is correct; create health endpoint |
| 429 | Rate Limited | Yes | Exempt health endpoint from rate limiting |
| 500 | Server Error | Yes — urgent | Application crash or unhandled exception |
| 502 | Bad Gateway | Yes — urgent | App server down; proxy can't reach it |
| 503 | Unavailable | Yes | Overloaded or maintenance; use maint. windows |
| 504 | Gateway Timeout | Yes — urgent | App too slow; investigate DB or CPU |
| timeout | No response | Yes | Server unreachable or overloaded |
Building a health check endpoint
The cleanest monitoring setup uses a dedicated /health endpoint — a route in your application that returns 200 when everything is working and a 5xx when something is wrong. This avoids the ambiguity of monitoring user-facing pages and gives you precise control over what "up" means.
A minimal health check:
// Express.js example
app.get('/health', async (req, res) => {'{'}
try {'{'}
// Check database connectivity
await db.query('SELECT 1');
res.json({'{'} status: 'ok', uptime: process.uptime() {'}'});
{'}'} catch (err) {'{'}
res.status(503).json({'{'} status: 'error', message: err.message {'}'});
{'}'}
{'}'});
Point your PingBase monitor at this endpoint. It returns 200 when the database is reachable, 503 when it's not. Simple, unambiguous, and decoupled from your actual user-facing content.
Set up HTTP monitoring that actually catches problems
PingBase HTTP monitors check status codes, response time, SSL certificates, and response body content. Free for up to 5 monitors.
Get started free →Related
How to Monitor Your API Endpoints
Custom headers, expected response codes, and response body checks for API monitoring.
Response Time Alerts: Slow Is the New Down
A 200 that takes 8 seconds is still a problem. How to monitor performance, not just availability.
Uptime Monitoring Best Practices
The complete setup guide including health endpoints, alert configuration, and status pages.