HTTP Uptime. More Than a Green Dot

What "uptime" actually means

"The site is up" is a deceptively vague claim. A site can be up in any of these ways and still be broken:

• DNS resolves, but to the wrong IP.
• TCP connects, but TLS handshake fails (cert expired, mismatched).
• HTTP returns 200 OK, but the page takes 8 seconds to load.
• HTTP returns 200 OK on the homepage, but every API endpoint 500s.
• HTTP returns 200 OK with a "site down for maintenance" body.
• Status code is 200 but the response is HTML for the wrong domain (load balancer misroute).

Real uptime monitoring catches at least the first three. Anything that just pings TCP port 443 and calls it "up" is monitoring the wrong thing.

What to actually measure

1. DNS resolves. The domain returns A/AAAA records. Cheap, but catches DNS-level outages.
2. TCP connects to port 443. Confirms the IP is reachable.
3. TLS handshake completes. Confirms the cert is valid and the server is responding.
4. HTTP GET succeeds. Returns a status code, headers, body.
5. Status code is acceptable. 200, 301, 302 are pass; 4xx is warn (depending on which); 5xx is fail.
6. Response time is acceptable. Sub-second is great; over 3 seconds is a fail even if the response was 200.
7. Redirect chain is sane. http:// → https:// with one redirect is normal. Eight redirects ending in a loop is a fail.

Status code and timing thresholds

Check frequency vs cost vs noise

More frequent ≠ better. The trade-offs:

• 1 minute: gold standard for production. Catches outages within ~2 minutes. Burns through API quota fast on metered monitoring services.
• 5 minutes: practical default. Catches outages within 5-10 minutes. Cheap.
• 15 minutes: appropriate for low-traffic informational sites. Don't use for revenue-critical infrastructure.
• 1 hour: bordering on useless for uptime, but fine for "this hasn't been completely abandoned" checks.

DomainsDoc runs checks every hour for paid plans, which is fine for the combined-monitoring use case (you're catching SPF/DKIM/blacklist/cert changes, not 60-second outages). If you need sub-minute uptime, pair us with a dedicated uptime monitor. UptimeRobot, Better Uptime, BetterStack. The two are complementary.

Filtering false positives

Single check failures are noisy. Real-world uptime monitoring needs to be robust against:

• CDN edge dropping a request (the next request gets a different edge).
• Brief TCP reset during a deploy.
• Monitoring location's network glitch.
• Garbage-collection pause on the server.

The standard mitigation is "require N consecutive failures before alerting." 2 is the most common, 3 if you tolerate slightly delayed alerts in exchange for fewer wakeups.

For services with a CDN, you should also check from multiple geographic locations, a single edge POP failing is normal and recoverable; multiple POPs failing is a real incident.

Multi-region monitoring

For revenue-critical services, a single monitor in one region misses regional issues entirely. A CDN edge failure in São Paulo never registers if your monitor is in Frankfurt.

The practical setup:

• 3+ geographic regions, ideally one per major continent you serve.
• Alert only when 2+ regions agree on a failure.
• Separate dashboard view per region so you can spot regional issues even without alerting.

What DomainsDoc covers and doesn't

We're not your primary uptime monitor, we're the cross-cutting infrastructure monitor that catches problems uptime tools miss:

• Your dedicated uptime monitor pings every minute and tells you when the page stops loading.
• DomainsDoc checks hourly across SPF, DKIM, DMARC, MX, blacklists, SSL, domain expiry, and HTTP, so when "the page is slow today," you know whether it's also an SSL renewal failure (cert just got reissued and isn't picked up yet) or a DNS issue (your registrar's nameservers are slow).

Use both together. We don't compete with uptime-focused tools; we cover the surface area they don't.

Alerting that doesn't burn out your team

• Escalate severity over time. A single failure pings Slack; 5 consecutive failures wakes someone up via SMS.
• Acknowledge alerts. Once a human knows about an incident, no more alerts for it until status changes.
• Group alerts by domain. Five things broken on one domain (because the server is down) = one alert, not five.
• Maintenance windows. Predictable downtime shouldn't generate alerts.

DomainsDoc supports email + Slack + Discord, deduplicates by domain+check_type, and only fires when state actually changes, not every check that confirms the failure.