Website monitoring that confirms downtime before it wakes you

What one HTTP check really does

Each check starts by resolving your hostname and refusing private or internal addresses, then opens a connection to the address it got and sends a plain request: your chosen method (GET by default), an Accept header of */*, no compression, and a Tenium-Monitor/1.0 User-Agent that links to our bot page. It reads the response body up to roughly 1 MB, stops the clock when the body has arrived, and stores that figure as the response time. That makes the number a "time to full page" rather than a time to first byte, which is closer to what a visitor waits for.

The result is then judged against exactly three things: whether the status code lies inside your expected range, whether the request finished inside the timeout, and, for https targets, whether the TLS handshake completed. The certificate expiry date is saved as a side effect of every https check, so the SSL warnings described in SSL monitoring need no second request.

• Timeout: 1 to 120 seconds, default 30. Ten to fifteen is a better setting for most sites, because a page that needs thirty seconds is already broken for users.
• Method: GET, HEAD, POST, PUT, PATCH or DELETE. HEAD is fast but some frameworks answer HEAD differently from GET, so a green HEAD check can hide a broken page.
• Interval: 5 min on Free, 1 min on Starter, 30 s on Pro and Agency.
• Basic auth and the X-Tenium-Secret header are available on every plan; arbitrary request headers need Pro.

Choosing the expected status range

The default range is 200-299. You can widen it to 200-399 if you would rather not follow redirects, narrow it to a single code, or list several values such as 200,301,302. Ranges and lists can be combined, for example 200-204,301.

Unusual targets are the reason this field exists. A staging site behind basic auth that answers 401 to anonymous visitors can be monitored with an expected status of 401: if the answer changes to 200, someone has removed the protection. A maintenance page that returns 503 on purpose can be tolerated during a planned window with a maintenance window, not by loosening the status range permanently.

Redirect chains and loops

Following redirects is on by default and Tenium will follow up to five hops. Every hop is written into the check details, so when a rewrite rule sends /shop to /shop/ to /shop and onwards, the incident shows the loop instead of a bare "too many redirects". Typical culprits are a CDN forcing https while the origin forces http, a www and non-www rule pointing at each other, and a language plugin that redirects based on a cookie the checker does not have.

If you switch redirect following off, the first response is judged as it is. That is the right setting when you specifically want to monitor that http://example.com answers 301, but remember to include 301 in the expected range or the monitor will fail by design.

Timeouts, slow origins and the slow threshold

A timeout failure reads "Timeout after 15 s" and counts as down just like a 500. Slow-but-alive is a different problem, and on Pro and Agency you can set a slow threshold in milliseconds. It compares the average of the last three checks against your number and opens a degraded incident instead of a down one, which is the right severity for a database under load. The $29 Pro plan is where this and custom headers live; see response-time alerts.

Pick the threshold from evidence: let the monitor run for a week, look at the response-time chart, and set the limit at about twice the typical value. A limit set at the median will page you every afternoon.

Why a healthy site can fail a check

Most false positives come from something between the checker and your server, not from the server itself. Bot-protection pages are the biggest group: a Cloudflare, Akamai, Imperva, Sucuri, DataDome or AWS WAF challenge is recognised and recorded as a "blocked" incident rather than "down", so you can tell a firewall decision from an outage. Rate limiters and fail2ban rules can ban a monitoring IP after a burst of retries; allow-list the addresses on the checker IP list or send an X-Tenium-Secret header that your firewall can match.

Then comes confirmation. When a check fails, other regions re-run it, and an incident opens only if the regions you asked for agree. With 2 regions live today, the standard setting is that all two regions must see the failure on plans that allow it; Free checks from 1 only. A monitor set to a single region alerts on its first failure, and the monitor page says so. Maintenance windows suppress incidents entirely while they are active.

What this check will not tell you

It does not run a browser. JavaScript is not executed, so a single-page app that serves an empty shell with a 200 will look healthy while users see a blank screen. For that, point a keyword monitor at server-rendered text, or at the JSON endpoint the app fetches. It also makes one request per check, not a journey through login and checkout, so it cannot tell you that a form submission fails. Treat it as the fast, cheap first line: it tells you the front door opens.