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.
Resolving is not the same as resolving correctly.
A DNS monitor resolves one record on your interval and fails when resolution fails.
A,AAAA,CNAME,MX,TXT,NS: pick the record, name the host, and the check asks the question a browser would ask first.It's the layer under everything else you watch. When DNS is wrong, your server is fine and nobody can reach it, and every other check you own goes red for a reason none of them can explain.
A record that disappears takes your site down loudly. A record that changes to someone else's address does something worse: it resolves, fast, and serves a stranger.
Set an expected value and the check fails when the answer doesn't contain it. That catches the hijack and the fat-fingered edit, not just the outage, and it's the difference between "DNS answered" and "DNS answered what I published".
The resolved records are stored and only rewritten when the answer set actually changes, so the monitor can tell you when your records last moved, not just what they say now.
A change you didn't make is worth a look. A change you did make, showing up on the timeline next to a deploy, is how you confirm propagation without reaching for
digon four machines.
Name a host and a record
The target is a bare hostname: no scheme, no path, no port. An IP address is refused, because resolving an IP is not a question DNS can answer.
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, Keyword, API, Heartbeat, Scheduler, and Port. Every one reports up, slow, or down, on the same interval, into the same alerts.