Use cases

Four situations this was built around, and the exact settings each one needs. If yours is not here, it is probably a variation on one of them.

An ecommerce catalogue

The problem: the homepage is up, so every monitoring tool says green — while a deploy has broken the template that renders half the product pages. You find out from a customer email.

What to do: one bulk monitor pointed at your sitemap with the path pattern /product/*, and a second one for /category/*. Each check pulls one address from the pool, so coverage builds up across the catalogue without five hundred rows in the dashboard. The failure streak is counted per address, which is what stops a permanently dead legacy product page from crying wolf every hour.

Add a required keyword that only appears when the page really rendered — the price element, the add-to-cart label — because a broken template usually still returns 200.

A JSON API

The problem: /health returns 200 whatever happens, because it was written to satisfy a load balancer rather than to tell the truth.

What to do: check the endpoint that actually touches the database, with a required keyword of "ok":true — exactly as your serialiser writes it, without a space, because the match is an exact substring. Add a custom header for your API token and set the expected status codes to 200 only, so a 401 from a rotated key shows up as a failure rather than as a passing 2xx.

Set the alert threshold to two or three. An API on a one-minute interval will produce the occasional single blip, and three false alarms teaches everyone to ignore the fourth.

An agency with client sites

The problem: forty sites across twelve clients, and the person who needs to know is different for each one.

What to do: one organisation per client, switched from the header. Members are unlimited on every plan, so invite the client themselves as a viewer — it is cheaper than forwarding the email, and it is the fastest way to demonstrate that you noticed before they did. Each organisation has its own signing secret, its own Slack or Teams webhook and its own alert recipients.

Put the weekly maintenance window on the monitors for clients who deploy on a schedule. Checks keep running and keep being recorded; only the alert is silenced.

A checkout or a login flow

The problem: the most valuable page you own is the one you can least afford to check often, because every other tool prices per check.

What to do: a one-minute interval, a POST with a body if the endpoint needs one, basic auth or a header token if it is behind a gate, and a forbidden keyword for the error text your framework prints when the payment provider is unreachable. Then ask for Core Web Vitals on that monitor: a checkout that renders in four seconds is a checkout people abandon, and that is an outage with a different shape.

A site behind Cloudflare, a WAF or a bot manager

The problem: your own monitoring is being challenged by your own protection, and the result is a red dashboard that means nothing.

What to do: read the guide on allowing the checks through. The short version is that our requests are identifiable and signed, so a skip rule can be written against something stronger than an IP list that changes.

Start monitoring in about a minute

Three monitors are free, forever. No card, no sales call — a link to your email address and you are in.

Get started — free