One thing we check, relentlessly.
A monitor is one target checked on one interval. Everything else — alerts, incidents, status pages, reports — hangs off its state. This page documents every knob.
Monitor types
| Type | What runs | Type-specific fields |
|---|---|---|
http | An HTTP(S) request; status and optionally content decide the state | method, headers, body, auth, redirects, cookies, expected status, keyword |
ping | An ICMP echo — honest network reachability, no HTTP stack involved | IP version |
tcp | A TCP connect to host:port — is the door open? | tcp_host, tcp_port |
dns | A DNS query, optionally against a specific resolver, optionally asserting the answer | dns_server, dns_query, dns_type, dns_expected |
Intervals, cost, regions
Intervals go down to 10 seconds on every plan — the form shows the monthly cost while you pick, and the same formula prints the receipt on the pricing page. Paused monitors send nothing and cost nothing. Regions: assign one or more check regions; the picker only offers regions we actually operate — multi-region monitors confirm state changes across regions before alerting.
Deciding up vs. down (HTTP)
expected_status_code | Pass on this status; unset means any 2xx/3xx success semantics |
alert_type: keyword | Body must contain keyword — a 200 without it is DOWN |
alert_type: keyword_absence | Body must NOT contain keyword — catches error pages served with 200 |
request_timeout_s | Per-check budget; a timeout is a failed check |
Slow is degraded, not down
A chronically slow server should not page anyone at 4 a.m. Monitors learn their normal response-time envelope; a response that is slow-but-alive shows as degraded — amber on charts and status pages, no alert. Genuinely failed checks (refused, timeout, wrong status, keyword miss) drive DOWN. You will see this as the amber band on every response-time chart.
Confirmation and recovery
One blip never alerts. A state change needs three consistent observations — and the
first failure triggers two instant parallel confirmation checks, so confirmation lands
seconds after first sighting, not a full interval later.
confirmation_period and
recovery_period extend this per monitor when you want a
target to be failing (or healthy) for longer before the state flips. A monitor that flips
repeatedly is flap-damped: it must hold stable before recovery is announced.
Request options (HTTP)
http_method | GET, HEAD, POST, PUT, PATCH, DELETE — with request_body where it applies |
request_headers | Name/value pairs sent with every check |
auth_username / auth_password | HTTP basic auth; the password is stored encrypted and never returned by the API |
follow_redirects | Follow 3xx (default on) or treat a redirect as the answer |
keep_cookies | Persist cookies across a redirect chain |
proxy_host / proxy_port | Check through your proxy |
ip_version | Force IPv4 or IPv6 |
Certificates and domains
ssl_verification fails checks on broken chains;
ssl_expiry_alert_days and
domain_expiry_alert_days warn before a certificate or the
domain registration runs out — the two outages that are always avoidable.
Maintenance windows
Planned work should not look like an outage: set
maintenance_from/maintenance_to
(with a timezone and optional weekday list) and checks in that window neither alert nor count
against availability. For one-off work, pausing the monitor does the same and costs nothing.
Organizing a fleet
Monitor groups fold a fleet into folders; free-form metadata (owner, runbook link, cost center) rides along on every monitor and is filterable via the API. Agencies scope monitors per client — see agency mode.
Via API
Everything above is a JSON field on POST /monitors — the reference lists all endpoints with a Try-It panel, and the batch-import recipe creates a whole fleet in one sitting.