Tune it when the defaults aren't right.
Interval, slow threshold, timeout, failure streak, redirects, SSL and domain expiry. Every knob the create form has, with a sane default on each.
Website & HTTP monitoring
Check that a URL is up and fast, from the edge.
Reads the whole response, not just the status line.
An HTTP monitor asks for your URL from the edge on your interval and reads the whole response, not just whether the connection opened. That distinction is the point: a 200 that took four seconds and a 200 that took forty milliseconds are not the same event, and only one of them is worth waking up for.
So every check lands in one of three states, up, slow, or down, rather than the binary that most tools stop at. Slow is a state of its own, not a flavour of up.
A check that reads the body splits its time three ways: DNS and connect, waiting for the first byte, and transferring the rest.
The split is what turns "the site feels slow" into a direction to look. Connect climbing is a network or DNS story. Waiting climbing while connect holds steady is your backend thinking. Transfer climbing is a payload that grew. A single response-time number tells you none of that.
Connection timing needs a response to time, so it appears on checks that fetch the body. A
HEADcheck, the default, reports total latency only.Status codes lie. A deploy that ships an empty shell, an error page served cheerfully as 200, a JSON endpoint that quietly starts answering
null: to the status line, all of it is fine.Content rules let the check assert on the response body, so a page that returns 200 and renders nothing is down, which is what your users would call it.
A monitor that pages you every minute for an hour is a monitor you mute, and a muted monitor is worse than no monitor. UptimeX alerts on the transition: once when it breaks, once when it recovers.
A confirmation streak sits in front of that, so a single blip that fixes itself on the next check never reaches you at all.
Point it at a URL
An HTTP monitor needs nothing but the URL. HEAD is the default method, since most endpoints answer it and it costs your server the least; switch to GET when you need the body, which content rules do.
Create one from the dashboard, or over the API with a project key. Everything the dashboard does, the API does:
Create returns the monitor including the result of its first check, so you know straight away whether you pointed it at the right thing. Every field except url is optional and takes the default in the table above.
Everything around the check.
Alerts on the change, not every minute.
Once when it breaks, once when it recovers, to Slack, Discord, a webhook, email, or your phone. A confirmation streak holds back the blips.
A status page your users can read.
Every monitor can back a public status page with ninety days of history, on your own domain, so the question answers itself.
Every outage, written down as it happens.
A confirmed failure opens an incident and keeps the timeline, detected to resolved. The first half of the post-mortem writes itself.
Planned downtime that pages no one.
Schedule a window and the monitors it covers stop being checked, so nothing alerts, no incident opens, and the time is left out of your uptime.
Everything else you can watch.
Keyword, API, Heartbeat, Scheduler, DNS, and Port. Every one reports up, slow, or down, on the same interval, into the same alerts.