Writing checks#

Creating your first check covers the basics: a name, a target, and a schedule. This guide covers the rest of the check form — the options that decide exactly what “healthy” means for a given target, and when you’re told about it.

If instead you want to be alerted when your own system stops calling us — a cron job, a backup script — that’s a heartbeat check, not one of these.

Schemes#

The prefix on your target URL picks the checker. On the form this is the Check type choice, and the fields that don’t apply to the type you pick are hidden.

How often a check runs#

Check interval is how often the check runs in total, however many monitors are assigned to it. Your plan sets the shortest interval you can choose (see Plans and billing).

When more than one monitor runs the same check, they take turns rather than all firing at once. Each monitor runs it every interval × number of monitors, offset from one another so that together they hit the target once every interval, evenly spaced.

For example, a check with a 60-second interval on three monitors runs once a minute overall — but each individual monitor only runs it every three minutes. That keeps the load on your target constant however many vantage points you add. If you look at one monitor’s results for that check and it seems to be running “too rarely”, this is why.

Response conditions#

These decide whether an otherwise-successful connection still counts as a failure:

• Timeout — how long a single attempt may take before it gives up and counts as a failure. Your plan sets the maximum.
• Check for string — require the response (or, for tls://, a short certificate summary of subject/issuer/expiry) to contain or not contain some text.
• Redirects (http/https only) — by default a redirect chain is followed and the final response is evaluated. Tick Do not follow redirects to evaluate the first response as-is instead.
• Response code (http/https only) — by default any status 400 or above fails the check. You can replace that with an explicit comparison (equals / less than / greater than a status code) instead.
• Max response time — fails the check if a response arrives after this many milliseconds, even if everything else passed. Leave it at 0 for no limit. This is separate from the timeout, which only decides when a check gives up altogether.
• Certificate expiry (https/tls only) — fails the check once the presented certificate has this many days or fewer left before it expires. Leave it at 0 to not check this at all. This is a paid-plan feature.
• Certificate verification (https/tls only) — turn off TLS certificate verification for a target with a self-signed certificate, or one issued for a different hostname than the one you’re actually dialling (a Synology or router admin UI on your LAN is the common case). This is the curl -k equivalent — only use it for targets you trust.
• Invert result — flips the outcome of everything above, so the check fails when the target is reachable. Use it to confirm that something stays unreachable on purpose: a decommissioned service, or a firewall rule that should be blocking a port. It’s applied last, after every other rule.

Request configuration (http/https only)#

• Basic Auth — a user name and password sent as an HTTP Basic Authentication header.
• POST data — when filled in, the check sends a POST with this body instead of a GET.
• Request headers — up to ten extra headers, such as a User-Agent or an API key.

These are the fields that can carry something sensitive. If they do, read Keeping shared monitors off a check below.

When you’re alerted#

• Down interval alert — how long the check must keep failing before a DOWN notification is sent. It can’t be shorter than the check’s own interval, and the maximum is 30 days. There’s a second requirement on top of the time: with two or more active monitors, at least two of them must be failing the check; with only one, it must have failed twice in a row. That is how a single monitor’s own bad connection is kept from raising an alarm.
• Resend while down — by default you’re told once when a check goes down and once when it recovers. Set this to also get a repeat STILL DOWN notification on this cadence for as long as the incident continues. 0 (the default) means never. It can’t be shorter than the check interval.
• Notify — which notification channels hear about this check. Only ticked channels are notified.

Recovery is quick: the first passing result from any monitor ends the incident and sends the RECOVERED notification.

Keeping shared monitors off a check#

Tick Never run this check on shared monitors if the request carries something sensitive — an Authorization/Cookie header or POST data — that you don’t want a machine you don’t operate seeing. This is always your own call, never inferred from the request. See Shared vs. private monitors, and restricted checks for the full picture of what this does and the other ways a check ends up restricted.

Keeping the check definition off the server entirely#

For something more sensitive than a header — an internal admin URL with credentials embedded, say — a private-definition check keeps the whole URL and match rule off the server permanently and only on the monitor(s) you choose. See Private-definition checks for the full workflow.

Showing a check on your status page#

Under Status on the check form, Public status page lists the check on your organisation’s public status page — its name, current status and 30-day uptime, and nothing else. It isn’t offered for a restricted check.

Duplicating, exporting and importing#

• Duplicate check (on a check’s edit page) makes a copy to adjust, rather than filling the form in again from scratch.
• Export on the Checks page downloads your checks as a JSON file, and Import creates checks from one — handy for moving checks between organisations or keeping a backup. A single check can be exported from its own row too, which is also the first step for a private-definition check.

Creating, duplicating and importing checks all count against your plan’s check limit — see Plans and billing.