HTTP status codes are the language your server uses to communicate the result of every request. For uptime monitoring, understanding which status codes indicate a healthy endpoint versus a broken one is essential — and the answer is more nuanced than "200 is good, 500 is bad."
HTTP Status Code Classes
HTTP status codes are grouped into five classes based on their first digit:
| Class | Range | Meaning | |-------|-------|---------| | 1xx | 100-199 | Informational (request received, continuing) | | 2xx | 200-299 | Success (request received, understood, accepted) | | 3xx | 300-399 | Redirection (further action needed) | | 4xx | 400-499 | Client error (request has an error) | | 5xx | 500-599 | Server error (server failed to fulfill a valid request) |
2xx: Success Codes
200 OK
The gold standard. The server received the request, understood it, and successfully returned the requested resource. Configure your monitoring to expect a 200 for most endpoints.
Monitoring implication: Accept as success. Combine with keyword checks to verify content is correct.
201 Created
The request succeeded and a new resource was created. Returned by POST requests that create resources.
Monitoring implication: For API endpoint monitoring that uses POST requests (like health check endpoints that create a test record), 201 is a valid success response.
204 No Content
The request succeeded but there's no response body. Common for DELETE requests and some health check endpoints designed to be lightweight.
Monitoring implication: Valid success. Note that keyword checks won't work here — the response has no body to check.
206 Partial Content
Used for range requests (streaming video, resumable downloads).
Monitoring implication: Valid success for streaming endpoints. Not expected from standard web pages.
3xx: Redirect Codes
Redirects require careful handling in monitoring. Your monitoring tool will follow redirects by default, but you should understand what's happening.
301 Moved Permanently
The resource has been permanently moved to a new URL. The server includes the new URL in the Location header.
Monitoring implication: Usually a sign of correct configuration (HTTP → HTTPS redirect, www → non-www). Monitor the final destination URL, not the redirecting URL, to avoid measuring redirect overhead. Alert if a 301 appears on a URL that shouldn't be redirecting.
302 Found (Temporary Redirect)
Temporary redirect. The resource is temporarily at a different URL.
Monitoring implication: Often indicates application-level redirects (redirecting to login page). If your monitoring sees a 302 where it expects 200, it likely means the authentication check failed.
304 Not Modified
The resource hasn't changed since the client's last request. The server sends no body.
Monitoring implication: If your monitoring tool sends If-Modified-Since headers, you might get 304s. Configure monitors to not send cache headers, or accept 304 as success.
4xx: Client Error Codes
These indicate the request itself has a problem. From a monitoring perspective, they almost always indicate something wrong.
400 Bad Request
The server can't understand the request due to malformed syntax.
Monitoring implication: Usually indicates a monitor configuration problem (malformed request) rather than a server issue. Check your request format first.
401 Unauthorized
The request requires authentication and none was provided.
Monitoring implication: Your monitor is hitting a protected endpoint without credentials. Either add authentication to the monitor or monitor a different URL. See our guide on monitoring authenticated endpoints.
403 Forbidden
The server understood the request but refuses to authorize it.
Monitoring implication: Your monitoring IP may be blocked, or the resource requires specific permissions. Check if your monitoring provider's IPs are whitelisted.
404 Not Found
The server can't find the requested resource.
Monitoring implication: The URL doesn't exist. Either you've misconfigured the monitor URL, the page was deleted/moved, or a deployment removed the route. Always alert on 404.
429 Too Many Requests
The user has sent too many requests in a given time frame.
Monitoring implication: Your monitoring is being rate-limited. Reduce check frequency, or whitelist monitoring IPs in your rate limiting configuration.
5xx: Server Error Codes
These indicate the server experienced an error fulfilling a valid request. All 5xx codes should trigger immediate alerts.
500 Internal Server Error
A generic error indicating the server encountered an unexpected condition.
Monitoring implication: Your application crashed or threw an unhandled exception. Immediate investigation required.
502 Bad Gateway
The server, acting as a gateway or proxy, received an invalid response from an upstream server.
Monitoring implication: Usually indicates your upstream application server (Node.js, Python, Ruby) is down, and your reverse proxy (nginx, Apache, load balancer) is returning an error. The web server is alive, but what's behind it isn't.
503 Service Unavailable
The server is temporarily unable to handle the request, typically due to being overloaded or down for maintenance.
Monitoring implication: Most commonly seen during deployments or when the server is overloaded. Should trigger an alert (unless inside a maintenance window). The most common status code during real outages.
504 Gateway Timeout
The server, acting as a gateway, did not receive a timely response from an upstream server.
Monitoring implication: Your upstream application is responding, but too slowly. Often indicates database connection issues, external API calls hanging, or application-level performance problems.
Configuring Status Code Expectations in Monitoring
Most monitoring tools, including AzMonitor, let you configure which status codes count as "success" for each monitor:
# Standard webpage monitor
expected_status: 200
follow_redirects: true
max_redirects: 3
# API health endpoint that returns 204
expected_status: 204
keyword_check: false # No body to check
# Endpoint that should redirect
expected_status: [200, 301] # Accept either
follow_redirects: false # Don't follow - verify the redirect itself
# Authenticated API (will return 401 without auth)
expected_status: 200
auth_type: bearer
auth_token: "${MONITORING_TOKEN}"
The "200 But Broken" Problem
A critical insight: a 200 OK doesn't always mean your site is working. Your server might return 200 with an error page, a maintenance notice, or cached stale content. This is why keyword monitoring exists.
Always combine status code checks with keyword verification:
- Status code check: Server is responding with the right HTTP code
- Keyword check: Response body contains expected content
Together, they confirm the full request-response cycle is working correctly. AzMonitor supports both checks on every monitor — configure yours for free.
Related: see our guide on how uptime monitoring works technically for more detail on how monitoring tools process HTTP responses.
3 monitors free forever · No credit card needed · Set up in 2 minutes
Start monitoring free →