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.
Keyword monitoring
Verify the response actually contains the text you expect.
A page that loads but says the wrong thing is down.
A keyword monitor makes the same request an HTTP monitor does, then reads what came back. The status line says the server answered; the body says whether it answered with your site.
Those are different questions, and only one of them is the one your users are asking. A keyword check fails a page that returns 200 and renders nothing, which is what everyone but the status code would call down.
A rule either requires text or forbids it. Require the string that only appears when the page really rendered, a heading, a price, a username in the nav. Forbid the string that only appears when it didn't:
Something went wrong,502 Bad Gateway, your framework's error banner.Set both and you have described what "working" means far more precisely than any status code does. Every rule has to pass; one failure is a down.
An HTTP check can get away with
HEAD, which asks for headers and no content. A keyword check can't judge a body it never asked for, so adding a rule switches the request toGETon its own.That means it costs your server a real response every interval. Point it at a page you're happy to serve, and prefer a small one: a health endpoint that prints a word beats the homepage.
Say what the page must say
Matching is literal and case sensitive: the check asks whether the raw body contains your string, exactly as you typed it. Dashboard will not match dashboard. There is no regex, and no wildcards.
Pick text that is boring and load-bearing. A copy tweak shouldn't page you at 3am, so avoid marketing lines, and avoid anything a logged-out visitor never sees.
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.
HTTP / Website, API, Heartbeat, Scheduler, DNS, and Port. Every one reports up, slow, or down, on the same interval, into the same alerts.