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.

Schemes#

The prefix on your target URL picks the checker:

Scheme	What it does
`http://` / `https://`	Fetches the page. Supports all the response conditions below.
`tcp://host:port`	Opens a raw TCP connection, optionally checking for a banner.
`tls://host:port`	Performs a bare TLS handshake with nothing else on top — for a service that expects TLS as the very first bytes on the wire (SMTPS, IMAPS), where `https://` won’t speak the right protocol and `tcp://` will just time out waiting for a plaintext banner it’s never going to get.

Response conditions#

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

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.
Status 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 unset for no limit.
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.
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.

Down interval alert#

The Down interval alert slider controls how many consecutive failures (across however many monitors run the check) are needed before a DOWN notification actually fires. It can’t be set shorter than the check’s own interval, so it always corresponds to at least one real failed attempt — often two, if only one monitor is assigned.

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.