Monitors

HTTP, TCP, DNS, ping, keyword, and heartbeat checks — the building blocks of everything else.

Monitors

A monitor is a recurring check against an endpoint. Every minute the scheduler queries which monitors are due, dispatches a workflow per monitor, runs the probe from each configured region, aggregates the results, and updates state.

Types

HTTP — most common

Issues an HTTP request and grades the response.

Configurable: method (GET/POST/PUT/PATCH/DELETE/HEAD/OPTIONS), headers, body, expected status codes, response keyword assertions, request timeout, follow redirects, basic/bearer/header auth.

Captures: status code, full timing waterfall (DNS / connect / TLS / TTFB / transfer), response headers snapshot, body hash, SSL expiry, domain expiry.

Keyword

Same as HTTP, plus searches the response body for a substring (contains) or its absence (not_contains). Useful for verifying that a deploy went through, that a banner is gone, or that a marketing site hasn't been hijacked.

TCP

Opens a TCP socket to host:port. No HTTP layer. Useful for SSH, SMTP, MySQL, Postgres, Redis, custom protocols.

DNS

Resolves a hostname via DNS-over-HTTPS (1.1.1.1) and asserts the answer matches an expected record set (A, AAAA, CNAME, MX, TXT…).

Ping (ICMP)

Issues an ICMP echo. Returns RTT.

Heartbeat (push)

The opposite of every other type — instead of Happy Uptime calling out, your job calls in. Use for cron jobs and scheduled tasks. See the heartbeat guide.

States

A monitor is always in one of:

State	Meaning
`up`	All regions reported success on the last check
`degraded`	Some regions failed, but not all — partial outage
`down`	All regions failed
`paused`	Manually paused; no checks dispatched
`unknown`	Not yet checked, or in a maintenance window

Transitions are confirmed before they fire alerts: by default a monitor must fail two consecutive checks (or wait confirmation_period_s) before flipping to down. Same on the way back to up (recovery_period_s).