HTTP monitors

An HTTP monitor asks your URL the same question on a schedule, from several places at once, and tells you when the answer changes. That is the whole idea. Most of what follows is about the two questions people actually get wrong: what counts as “up”, and how sure we should be before we wake you.

Making the request

You choose the method — GET, HEAD, POST, PUT, PATCH, DELETE or OPTIONS — and can add request headers and a body. GET is the default and is what you want for most checks.

Redirects are followed by default, up to five hops, and you can turn that off if the redirect itself is the thing you care about. A monitor that follows redirects reports on wherever it lands; one that does not will report a 301 as a 301, which is the point when you are watching for an unexpected one.

HEAD is cheaper, when it works

If you only care that the server is answering, HEAD skips the response body. Not every server implements it properly — some return 405, some return a 200 with different headers than the GET would — so check the monitor goes green before you rely on it.

What counts as “up”

By default: the request completed and the status code was in the 2xx range. Anything else — a 500, a connection refused, a TLS failure, a timeout — is a failure.

That default is often not enough. A 200 OK means the server answered; it does not mean the answer was right. An API that returns 200 with {"status":"degraded"}, a page that serves a cached error, a login form that silently starts returning the logged-out version — all report green.

Checking the response covers how to assert on the status code, any response header, the body, or a field in the JSON, so those cases open an incident instead.

If the endpoint needs credentials, see endpoints that need a login — basic auth, bearer tokens, and an OAuth2 client-credentials grant that refreshes itself so an expiring token never becomes a false outage.

Timeouts, and “slow” as distinct from “down”

The timeout is how long we wait before calling the attempt failed. It can be set between one and twenty seconds.

Separately, you can set a degraded threshold: a response time above which the check is recorded as degraded rather than up. Degraded still counts as up for uptime percentage — the service answered — but it shows amber on the charts and can be routed differently in your alert rules. It is the right tool for “this is still working but something is wrong”, which is usually the state you would rather hear about before the outage.

Where we check from

Every check runs from multiple regions in parallel. There are 13 to choose from:

• 🇺🇸 US East (Virginia)
• 🇺🇸 US West (Seattle)
• 🇨🇦 Canada (Toronto)
• 🇬🇧 UK (London)
• 🇩🇪 Germany (Frankfurt)
• 🇸🇪 Sweden (Stockholm)
• 🇯🇵 Japan (Tokyo)
• 🇸🇬 Singapore
• 🇦🇺 Australia (Sydney)
• 🇮🇳 India (Mumbai)
• 🇮🇳 India (Delhi / Hyderabad)
• 🇧🇷 Brazil (São Paulo)
• 🇿🇦 South Africa (Cape Town)

Checking from more than one place is not about coverage for its own sake — it is what tells a real outage apart from a network problem between one of our regions and you. Which brings us to the part that decides whether your phone rings.

How sure we are before paging you

Three settings, and they compose:

Failures before incident. How many consecutive failed checks it takes to open an incident. The default is 1. Raising it trades a little detection speed for immunity to one-off blips.

Regions required to alert. How many regions must agree that the check is failing. A monitor probing five regions with a quorum of three will not open an incident when a single region has a bad path to your host — which is the single most common cause of a false page in any monitoring tool.

Successes to recover. How many consecutive passes before the incident is marked recovered. Raising it stops a flapping service from sending you an alternating stream of down-and-up.

A quorum larger than your region count never fires

If you set a quorum of three and then reduce the monitor to two regions, the condition can never be met and the monitor will not alert at all. The dashboard caps the quorum at the number of regions selected, but it is worth knowing why the cap is there.

How often

The fastest interval and the number of regions depend on your plan:

Plan	Fastest interval	Regions per monitor
Free	5 minutes	2
Starter	30 seconds	3
Pro	15 seconds	4
Business	15 seconds	5
Enterprise	15 seconds	13

Every region checks on every interval, so a one-minute monitor across five regions is five checks a minute. That is worth knowing when you pick both numbers.

What gets recorded

Each check stores its outcome, the response time, time-to-first-byte, the response size and the status code, per region. Those are what the charts on the monitor page are drawn from, and what the badges, embed and JSON outputs expose publicly if you want them.

When a check fails, the reason is recorded in a form you can act on — connection refused, TLS expired, timeout, a specific assertion that did not hold — rather than a generic “down”. That reason is what appears in the alert, so the message you get at 3am says which thing broke.