“Is the site up?” sounds like a yes/no question. In practice, up depends on what you check and how — and getting that wrong means either missing real outages or drowning in false alarms at 3am.
HTTP vs TCP checks
The two most common check types answer different questions.
| TCP check | HTTP check |
|---|---|
| Confirms a port accepts connections | Confirms the app returns a valid response |
| Fast and lightweight | Sees status codes, redirects, and content |
| Can't tell a 500 error from a healthy page | Catches app-level failures, not just network |
| Good for databases, SMTP, custom services | Good for websites and APIs |
A TCP check tells you the server is reachable on a port. An HTTP check goes
further: it makes a real request and inspects the status code — so a server
that’s accepting connections but returning 500s reads as down, which is
usually what you actually want.
How often should checks run?
More frequent isn’t always better — it’s a trade-off between how fast you detect an outage and how much noise you tolerate.
- Critical, customer-facing sites: every 30–60 seconds
- Internal tools and lower-stakes services: every 5 minutes is plenty
- Require 2+ consecutive failures before alerting to filter blips
- Check from outside your own network so you catch DNS and routing issues too
What counts as “down”
A single failed request is rarely a real outage — a dropped packet, a brief GC pause, a transient DNS hiccup. The fix is confirmation: only open an incident after a couple of consecutive failures, and resolve it automatically when checks recover. That one rule eliminates most false alarms.
You can sanity-check any URL right now with the HTTP status checker or get a quick read on a domain with the domain health checker — no signup required.