Uptime check pass conditions

An HTTP uptime check passes only when every pass condition holds. Add them under Pass conditions when you create or edit a check — up to 10 per check. There are no regular expressions and no scripts: each condition is a plain comparison, so a check means the same thing in every region.

TCP checks have no conditions: they pass when the connection opens within the timeout.

Defaults#

• Status code — without a status condition, 2xx passes. When Follow redirects is off, 3xx passes too, because the redirect itself is the answer.

• Valid TLS certificate — added to every new check. For an https:// URL the certificate must be trusted and match the host name; an expired, self-signed or wrong-host certificate fails the round. Remove the condition only if you really serve such a certificate. It has no effect on http:// URLs.

Conditions#

Details:

• Body conditions read the first 64 KB of the body after decompression (gzip, deflate, br; at most 1 MB unpacked). Text past that point is not seen. Matching is case-sensitive unless you tick ignore case. A HEAD request has no body, so body and JSON conditions need GET.

• JSON value uses a JSON pointer (RFC 6901): /data/items/0/id is the id of the first item; write ~1 for a / and ~0 for a ~ inside a key. Equals compares strings as written and every other value as its JSON text — true, 3, null. Type is one of string, number, boolean, object, array, null. A body that is not valid JSON fails every JSON condition.

• Header names are case-insensitive; values compare exactly as sent.

• Response time is the total of DNS, connect, TLS, first byte and download, measured on the probe. After a redirect it is the last hop's time.

• Texts and values are up to 256 characters.

Order and failure reasons#

Conditions are checked in a fixed order and the first one that fails names the reason shown on the check page and in alerts. A round that cannot even get an answer fails earlier, with a network reason.

A few results are unknown, never a failure, because they say nothing about your service: not run — too many checks to the same host at once, address blocked (the name now resolves to a refused address — fix the target) and probe error. See how Belvador decides.

Request headers#

You may send up to 10 headers, for example an x-health-token your endpoint expects. authorization, cookie, host, content-length, transfer-encoding, connection, te, upgrade and any proxy-* or sec-* header cannot be set. Header values are part of the check settings, which every workspace member can read — use a token made only for health checks, never a user's credentials. When a redirect goes to another origin, your headers are not sent there.

Every request carries User-Agent: BelvadorUptime/<version> (+https://belvador.dev/docs/uptime/probes); see Probes and IPs.

Recipes#