Customizing and configuring alerts for website availability based on HTTP status codes

Your web server has been trying to tell you something. It speaks in three-digit codes—200, 301, 404, 503—each one a precise signal about what just happened and why. The problem is that most uptime monitors only hear two words: up and down.

This is the quiet failure mode that most website uptime monitoring setups share: they treat HTTP status codes as binary. A 200 code is up. Anything else is down. It's a simple rule that sounds reasonable until your production environment starts proving it wrong, one false positive monitoring alert at a time.

The truth is, HTTP status codes aren't just pass or fail signals. They're the language your web server uses to convey a website's status. Learning to read them correctly—and teaching your monitoring tool to do the same—is the difference between alerts you can trust and a queue full of noise. To understand why this matters, it helps to know what these HTTP status codes are actually saying and why your monitor needs to speak the same language.

What HTTP status codes are trying to tell you

Every time your monitoring tool checks a URL, the server responds with a three-digit code. That code tells you whether the page loaded, redirected, bounced back an error, or the server itself gave up. There are five classes, and each one means something distinct:

1xx: Informational. The server received the request and is still processing. These codes are rarely seen in monitoring contexts, but it's worth knowing they exist.

2xx: Success. The request was received, understood, and completed. HTTP 200 is the standard, but this class includes 201 (Created), 202 (Accepted), 204 (No Content), and 206 (Partial Content), all of which can be perfectly healthy responses depending on your endpoint. A POST endpoint that returns 201 isn't broken. A health check endpoint that returns 204 isn't broken either. But a monitor that only wants to see 200 will label anything else as down.

3xx: Redirection. The resource has moved. 301 and 302 are common redirects; 304 means the browser cache is still valid. These aren't failures—but unmonitored redirect chains can mask real problems.

4xx: Client errors. The request is malformed, unauthorized, or not found. 400, 401, 403, and 404 are the usual suspects. Most of the time these indicate a problem, but on an authenticated endpoint, a 401 before login is the expected healthy response. If your monitor doesn't know that, it will alert you about this normal behavior.

5xx: Server errors. The server couldn't complete a valid request. 500 (Internal Server Error), 502 (Bad Gateway), 503 (Service Unavailable), and 504 (Gateway Timeout) are the codes that need your immediate attention.

Where the "200 only" default breaks down

Most default website downtime alerting setups accept HTTP 200 as uptime and mark everything else as downtime. In practice, this creates three problems that erode trust in your alerts over time.

False positives from valid non-200 responses. An API that returns 201 after a POST will trigger continuous false alerts if your uptime check is hardcoded to expect 200. A CDN returning 206 for range requests, or an API health check returning 204, will look like outages to a monitor that doesn't understand the context. You'll spend more time triaging alerts that aren't incidents than catching the ones that are.

False negatives on authenticated endpoints. Internal tools and staging environments often require authentication. If the monitor hits a login wall and gets a 401, a naive monitor might log a configuration error instead of reflecting the real service state, hiding a genuine availability problem behind a misclassification.

Lost nuance in 5xx detection. Not every 503 is a crisis. A planned maintenance page returning 503 on a Sunday night is fine. An unplanned 503 on your checkout endpoint during peak traffic is not. Without the ability to define what's acceptable for each endpoint individually, your alerts can't make that distinction.

That's where custom HTTP status code thresholds change the equation, letting you define what healthy looks like for each endpoint individually.

How Site24x7 handles custom HTTP status code thresholds

Site24x7's Accepted HTTP Status Codes feature lets you define exactly which response codes count as a successful uptime check response for each monitor individually. You enter codes as comma-separated values or as ranges using a colon separator. For example, 200:204 accepts everything from 200 through 204, and 200, 401 accepts both codes as healthy responses.

This feature is available across website monitors, REST API monitors, webpage speed monitors, and API transaction monitors, covering the full range of endpoints most production environments need to watch.

Here's how common scenarios map to practical configurations:

The logic of accepted HTTP status codes is straightforward: Site24x7 checks the response code against your accepted list. A match means the monitor is up. Anything outside the list triggers a Down or Trouble alert, depending on how you've configured alert severity. Here's how to put that into practice.

Configuring HTTP status code alerts in Site24x7

For a website monitor:

• Log in to Site24x7, navigate to Admin > Inventory > Monitors > Add Monitor > Website.
• Enter your URL and navigate to the HTTP Configuration section.
• In the Accepted HTTP Status Codes field, enter your comma-separated codes (e.g., 200, 201, 204) or as a range using a colon separator (e.g., 200:204).
• Click Check Availability to verify the URL returns one of your accepted codes before saving.

Read our help documentation to get more website monitor configuration details.

For a REST API monitor

Go to Admin > Inventory > Monitors > Add Monitor > REST API. The Accepted HTTP Status Codes field works identically—individual codes or colon-separated ranges. For REST API uptime checks, this is especially important for POST and PUT endpoints that return 201 or 204 by design. A GET health check endpoint at /api/health returning 204 is healthy; configure it that way from the start, or every check will return a false Down alert. Getting the accepted codes right is the first step. The second is making sure the right alert fires when they're violated.Read our help documentation to find more details on adding a REST API monitor.

Tuning alert severity: Down vs. TROUBLE

Not every unexpected status code warrants a 2am page. Site24x7 lets you toggle alert severity between Down or TROUBLE.

Use Down when an unexpected response means something is definitively broken and needs immediate action. Use TROUBLE when the response is worth investigating but doesn't warrant an immediate escalation. For the most critical failures—like sustained 5xx errors on production APIs—one alert isn't enough.

Persistent alerts for sustained 5xx errors

For production APIs where a stream of 500 errors needs to page the on-call engineer at every occurrence, not just the first, use Site24x7's persistent alert configuration. Navigate to Admin > Configuration Profiles > Notification Profile and set the Notify After Every field to 1. This ensures a fresh alert fires for every new matching log entry, not just when the monitor first transitions to Down.

This is particularly valuable for back-end services where a sustained 500 error stream indicates an ongoing failure that needs continuous visibility—not a single alert that gets buried after the first notification. On the other end of the spectrum, a single location reporting an unexpected code isn't always a real incident.

Read more about notification profiles.

Reducing false positive monitoring alerts with multi-location checks

A single monitoring location reporting an unexpected status code might be a transient network issue, not a real outage. Before triggering a Down alert, require confirmation from multiple locations. Site24x7 lets you select up to eight monitoring locations when customizing downtime rules. For critical endpoints, requiring two or three independent locations to confirm a non-accepted response is the most effective way to reduce false positives in HTTP status code monitoring without sacrificing detection speed.

With those building blocks in place, here's how they come together for the endpoint types most teams are actually monitoring.

Common endpoint configurations worth bookmarking

Here are some of the common endpoint configurations you can save:

• E-commerce checkout: Accept 200, 201. Alert as Down on 500 or 502 immediately. Alert as TROUBLE on 503, as it may indicate a queue backup before it becomes a full outage. Enable persistent alerts for 500 errors.
• Login and authentication wall: Accept 200, 401. A 403 should alert as TROUBLE, as it may indicate an ACL change. A 500 should alert as Down.
• Internal API health check: Accept 200, 204. A 404 should alert as Down—the endpoint has been removed or misconfigured. A 503 should alert as Down.
• CDN-fronted asset endpoint: Accept 200, 206. A 404 should alert as TROUBLE (asset missing). A 502 or 504 should alert as Down (origin unreachable).
• Staging environment: Accept 200, 503—maintenance windows are expected here. Alert only on 500 or connection timeouts.Every endpoint in your stack has an expected response. These configurations make sure your alerts match that expectation, not ignore it.

Your monitor is only as accurate as your configurations

A status code is only meaningful if your monitor knows what to expect from that specific endpoint. A payment gateway returning 202 isn't broken—it's telling you the request was accepted and will be processed asynchronously. A health check returning 204 isn't down—it's responding correctly with no body, exactly as designed. A staging environment returning 503 on a Sunday isn't an incident—it's offline on schedule. But a monitor fluent in only one code—200—will flag all three as failures. Over time, that noise trains your team to ignore the alerts that actually matter.

This is where a website monitoring tool that supports custom HTTP status code thresholds earns its place. Rather than applying a single global pass/fail rule across every endpoint in your stack, Site24x7's website monitoring lets you define exactly what a healthy response looks like for each monitor individually. So a 202 on your payment gateway and a 204 on your health check are both treated as the successes they are, not the failures they'd appear to be under a binary rule.

Start your 30-day, free trial with Site24x7—no credit card required

FAQ