Frequent Monitoring: Checking Your Priority Hosts Every 5 Minutes Instead of Every Hour

Most DNS records are stable for weeks or months at a time, which is why the default check interval is measured in hours rather than minutes. That default is the right trade-off for almost everything on almost every domain. It's also not fast enough for the handful of records where an hour of undetected drift is genuinely expensive, and that gap is what Frequent Monitoring closes.

What the default interval actually is

OneDollarDNS checks each host on an hourly interval by default. For a typical domain, that's more than fast enough: an MX record, an SPF record, an NS delegation, none of these change often, and none of them cost much if a change sits undetected for up to an hour before the next check catches it.

What Frequent Monitoring changes

Turning on Frequent Monitoring for a domain drops the check interval to every 5 minutes, but only for hosts you've specifically marked as a priority. It isn't a blanket setting that speeds up checks for an entire domain's worth of hosts, it's a targeted tool for the specific handful that actually need tighter detection.

Why priority hosts, not the whole domain

A domain can mark up to 50 hosts as priority. That cap exists because Frequent Monitoring is meant for the small set of records where five minutes of exposure genuinely matters, not as a way to blanket-upgrade every host on a large domain to the fastest tier. If everything feels urgent enough to mark as priority, that's usually a sign the actual bottleneck is deciding what's genuinely critical, not the size of the limit.

When 5 minutes is actually worth it

A root domain's A record. The apex is usually the highest-traffic hostname on a domain, and an unexpected change there redirects everyone at once. An hour of that going unnoticed is a meaningfully worse outcome than five minutes.

A business-critical MX record. MX records are close to the definition of "rarely changes," which is exactly why an unexpected one is worth catching in minutes rather than up to an hour later. There is no routine window where a change is expected, so any change at all is a meaningful signal, and every minute mail is misrouted or bouncing is a real, ongoing cost.

A CAA record you rely on. CAA records are set once and rarely touched afterward, which is exactly why an unexpected change is worth catching in minutes rather than an hour. The failure mode is also slower to surface than most: a misconfigured CAA record, the wrong CA authorized or none at all, does not break anything visibly the moment it changes. It just quietly blocks certificate issuance until the next renewal attempt actually runs, which can be days or weeks away, so catching the DNS-level cause early is the only realistic way to fix it before that renewal fails.

Anything you've already been burned by. If a specific host has caused an incident before, whether from an internal mistake or something external, marking it priority after the fact is a reasonable, deliberate response rather than something to set up preemptively on everything.

What it isn't for

Frequent Monitoring doesn't make detection instant, five minutes is fast relative to an hour, not real-time, and it doesn't change what happens after a change is detected, alerting and escalation work the same way regardless of which interval caught the change. It's specifically about narrowing the detection window on a small, deliberately chosen set of hosts, not a general "make everything faster" toggle.

Turning it on

Frequent Monitoring is enabled per domain, then applied by marking individual hosts as priority up to the 50-host limit. A host that stops being critical, say, after a migration it was added for is complete, is worth unmarking rather than leaving in the priority set indefinitely, since the limit is meant to stay a meaningful signal of what actually matters right now, not an accumulating list of everything that mattered at some point.