Uptime
HTTP check
Also called uptime check.
HTTP check is a probe that requests a URL and judges the response. A pass usually means a 200 within a time limit, sometimes with expected text.
How it is measured
Each run records DNS time, connect time, TLS time, time to first byte, status code, and total time. Pass criteria are status in the 200s (or exactly 200), response under 5 seconds, and optionally a body match such as Add to cart.
Interval and regions matter. A 1-minute check from three regions with a two-of-three rule is far less noisy than a single 5-minute check. Follow redirects deliberately and say how many.
Worked example
A realtor site is checked every minute at /listings?city=austin from Frankfurt, Virginia, and Singapore. The pass rule is 200, under 4 seconds, and a body containing sq ft. On the 8th the CMS starts returning a styled error page with status 200 and no listings.
A status-only check stays green. The body match fails in all three regions at 11:02, and the alert reaches the owner at 11:05. Reverting the plugin takes 12 minutes.
How it differs
HTTP check requests a URL and reads the reply. TCP check only opens a socket on a port. HTTP excludes services with no web server, such as SMTP or database ports. TCP excludes status codes and content, so a dead app behind a live port passes.
Common errors
Treating 200 as proof. Checking a cached static URL. Not following, or over-following, redirects. Ignoring TLS errors. Using one region. Running the check as a logged-in admin that bypasses the cache.
In practice
Add one check per user-critical path, not just the homepage. Give each a body match, and require two regions to agree. Keep the URL representative of real traffic. Run intervals between one and five minutes.