How it works

A check is a real HTTP request, made from the region you choose, judged by rules you set. Here is everything that happens between that request and the message that wakes someone up.

1. The request

Every minute, the scheduler picks up the monitors that are due and makes one request each. It is an ordinary HTTP request: your method, your headers, your body if you set one, and basic auth if the endpoint needs it. Redirects are followed by default — most people want to know whether the page works — but you can switch that off and assert that a 301 is still a 301.

We identify ourselves honestly. The user agent says Pingdomain and carries a link to a page explaining who we are, and every request carries an HMAC signature built from your organisation's secret, so your own servers can prove a request came from us rather than from someone claiming to be us. We will never disguise the checks as a browser to get past a block.

2. Where it is made from

Latency is a property of distance, so a check made from the wrong side of the planet measures the planet rather than your server. You choose a region per monitor — Europe, the United States or Australia — and the request is made from a worker pinned there.

This is not a detail. Measured against a Swedish ecommerce site: 24 ms from Stockholm against roughly 250 ms for the same page when the check happened to run in Taipei. Ten times the number, and none of the difference was at the customer's end. Every result records the datacentre it was actually measured from, so you are never left guessing whether a slow graph is your server or ours.

3. What counts as healthy

A check passes when all of the conditions you set are true:

Status code. Any 2xx by default; otherwise a list or a range, such as 200,204 or 200-299.
Keywords that must appear. One per line. A page that returns 200 while rendering "Database connection failed" is down, and only the body knows it.
Keywords that must not appear. The same, inverted — "Exception", "stack trace", the placeholder text from your CMS.

Keyword matching is an exact substring match, case-insensitive. It is deliberately not clever about whitespace: "ok": true does not find "ok":true, because a tool that finds matches you did not ask for is a tool that reports green when it should report red — the most expensive mistake monitoring can make.

4. The timing, split in two

Response time is recorded as time to first byte and download, separately, because they have different causes and different fixes. High TTFB is your server or the network thinking; a long download is size or bandwidth. Added together they hide each other, and a heavy homepage becomes indistinguishable from a slow database.

We do not claim more than we can measure. DNS, connection and TLS all sit inside that first number and cannot be separated in this runtime — so the field is called time to first byte, never "DNS time". For monitors where you ask for it, a real headless browser also measures Core Web Vitals once a day: LCP, FCP, CLS and the bytes transferred.

5. The alert

An alert is sent when the number of consecutive failures reaches the threshold you set — not when the status flips. That distinction is the difference between a tool that works and one that quietly stops: a threshold of three, counted from a state change, can only ever fire once, and after that the site is down in silence.

So: threshold one alerts on the first failure, threshold three waits for three in a row and alerts exactly once, and a recovery message follows when it comes back. Alerts go to email, a webhook, Slack or Teams. If a check fails without getting any response at all, it is retried once — and if the retry succeeds, you are told, because "failed once, then succeeded" is the signature of one unhealthy server behind a load balancer and worth knowing about.

6. When you are the one breaking it

Deploys at two in the morning every Tuesday should not page anyone. A weekly maintenance window silences the alerts for that period — but the checks still run and still get recorded. A gap in the history during a maintenance window is the worst possible place to have a gap: it is exactly when something might have broken.

What you do not have to do

There is no agent to install, nothing to deploy and no JavaScript in this interface at all. The dashboard is server-rendered HTML, the charts are inline SVG, and the whole thing works in a tab that has been open on a phone with bad reception for a week.