[1,213 words, 6 minute read time]
HTTP monitoring is the backbone of modern website uptime monitoring because it checks your site the way the web actually works: by requesting a URL over HTTP/HTTPS and evaluating the response.
But it also creates one of the most common frustrations in monitoring: “It says we’re down… but the site looks fine.”
Here’s the truth: most “down” alerts are configuration issues or edge cases—redirects, bot protection, timeouts, TLS hiccups, or a “200 OK” page that isn’t the page you meant to monitor.
This guide explains how HTTP monitoring works, how to interpret results, and how to configure checks so alerts reflect real user impact.
How HTTP checks work (GET vs HEAD, redirects, and TLS)
At a high level, an HTTP monitor:
- Connects to your target URL
- Makes a request (often GET or HEAD)
- Follows any redirects (depending on settings)
- Evaluates the response (status code, response time, optionally content)
GET vs HEAD (what’s the difference?)
- GET requests the page content (HTML/JSON/etc.).
- Best when you want to confirm the page really loads and contains expected content.
- HEAD requests only headers (no body).
- Often faster and lighter, but you can’t do content/keyword validation.
Practical rule:
If your tool offers it, use GET for critical pages (especially if you’ll do keyword checks).
Redirect handling (301/302 and beyond)
Many sites redirect:
- HTTP → HTTPS
- non-www → www (or the reverse)
- /home → /
- geo-based redirects
Most monitors can follow redirects, but you should:
- confirm the monitor is pointing at the final canonical URL
- ensure redirect chains are not excessive (more on that below)
TLS/HTTPS (why certificates matter)
For HTTPS monitoring, there’s an extra step before any HTTP response exists: the TLS handshake.
If TLS fails, the site can be “down” to users even if the server is running. Causes include:
- expired certificate
- hostname mismatch
- incomplete certificate chain
- unsupported TLS configuration for certain clients
This is why an HTTPS monitor can alert even when “the server is up.”
Status codes cheat sheet: what to alert on (and what not to)
Status codes are the fastest way to interpret HTTP monitoring results.
2xx — Success
- 200 OK: the page responded successfully
- 204 No Content: often fine for APIs
Usually: don’t alert
But watch out: 200 can still be “wrong content” (keyword checks help).
3xx — Redirects
- 301 Moved Permanently: standard canonical redirect
- 302/307 Temporary Redirect: common for login flows or experiments
Usually: don’t alert if redirects are expected and the final page loads
Do alert if: redirects loop, chain excessively, or point somewhere incorrect (like a login page).
4xx — Client-side errors (often “blocked” or “not found”)
- 401 Unauthorized: requires auth
- 403 Forbidden: blocked by WAF/bot protection, permissions issue
- 404 Not Found: page missing
- 429 Too Many Requests: rate limiting
Alert depends on context:
- If it’s a public page, 403/404 is usually a real incident.
- If it’s a protected endpoint, 401 might be expected.
- 429 could mean your monitor is being throttled.
5xx — Server-side errors (usually alert-worthy)
- 500 Internal Server Error: application error
- 502 Bad Gateway: upstream failure (load balancer/app server)
- 503 Service Unavailable: overload, maintenance mode, dependency failure
- 504 Gateway Timeout: upstream timeout
Usually: alert on these, especially if confirmed by retries/regions.
If you’re tuning alert policies and escalation, see alert best practices.
Keyword checks: confirm the right content loaded (the “is it working?” upgrade)
A plain HTTP check can be fooled. It might get a 200 OK while the site is effectively broken.
A keyword check solves this by confirming the response body contains something stable and expected—like:
- your brand name in the header
- a specific element or text unique to the page
- a “Welcome back” phrase on a dashboard
- a product price label (careful with dynamic content)
What keyword checks catch
- “200 but wrong page” (maintenance page, login page, cached error page)
- regional routing sending users to an unexpected version
- CMS template failures that render blank shells
- WAF returning a “blocked” page with 200
How to choose a good keyword
Good keywords are:
- stable (won’t change daily)
- specific (not “Home” or “Welcome”)
- unique to the correct page
- not user-personalized
Avoid: dynamic numbers, dates, rotating headlines, or personalized text.
Handling redirects and auth (without creating “false downtime”)
Redirects: point your monitor at the final destination
If your site redirects HTTP→HTTPS or non-www→www, configure your monitor to:
- use the canonical URL (usually HTTPS)
- follow redirects (if needed)
- alert only if it can’t reach the final page successfully
Auth-protected pages: monitor what you can reliably validate
If the page requires login, you have three options:
- Monitor the public page that indicates health (homepage, status endpoint, etc.)
- Use a keyword check on a semi-public page (like the login page itself)
- Use multi-step monitoring (login → dashboard) if your tool supports it
Common pitfall: monitoring a protected URL without proper config and getting 401/403 alerts that aren’t real incidents.
Recommended settings (timeouts and retries that reduce noise)
Most false downtime alerts happen because monitors are too “twitchy.”
Here are safe defaults for many sites:
Practical defaults
- Interval: every 5 minutes (adjust later)
- Timeout: 10 seconds
- Retries: 2 (confirm before alerting)
- Redirects: follow redirects (or monitor the canonical URL directly)
- Regions: 1–2 to start; more as your audience broadens
Want help deciding how aggressive to be? See check frequency.
Confirmation logic is your best friend
If your tool supports “confirm from another location” or “only alert after multiple failures,” turn it on. It prevents:
- one-off network blips
- single-region probe issues
- transient DNS hiccups
If you’re currently getting spammed, fix it with false positives.
Three common “down alert” edge cases (and how to fix them)
Example 1: “200 but wrong page”
Symptoms:
- Monitor shows 200 OK
- Keyword check fails (or users report issues)
Causes: - maintenance page returning 200
- cached error page
- unexpected redirect to login or geo page
Fix: - add a keyword check on a stable page element
- monitor the canonical URL and confirm final destination
Example 2: “301 chain”
Symptoms:
- Monitor reports excessive redirects, timeout, or redirect loop
Causes: - HTTP→HTTPS redirect plus www/non-www plus trailing slash rules
- misconfigured rewrite rules
Fix: - point monitor at the final canonical URL (usually HTTPS + correct host)
- reduce redirect hops; avoid loops
- confirm your tool follows redirects correctly
Example 3: “403 from bot protection”
Symptoms:
- Monitor reports 403 (or sometimes 200 with a “blocked” page)
- Real users can load the site
Causes: - WAF/bot protection blocking monitoring probes
- rate limiting triggers (429)
Fix: - allowlist monitoring IP ranges (if available)
- adjust WAF rules for your monitor user-agent/behavior
- reduce check frequency if you’re being throttled
- use keyword checks to detect “blocked page” responses even if they return 200
Troubleshooting flow: what to do when an HTTP monitor alerts
When you get an alert, ask:
- What status code is it? (5xx vs 4xx vs timeout)
- Is it confirmed by retries and/or multiple regions?
- Is it a redirect issue? (loop or chain)
- Could it be bot protection? (403/429)
- Could it be “wrong content with 200”? (use keyword checks)
This flow alone resolves a large percentage of “mystery downtime” alerts.
Add one keyword check to your most important page (CTA)
If you do one thing to make HTTP monitoring more reliable, do this:
Add a keyword check to your most important page (the page tied to revenue, signups, or leads).
It’s the fastest upgrade from “is up” to “is working,” and it eliminates a big chunk of confusing edge cases.