How to Schedule Automated DNS Health Checks

A one-time DNS lookup tells you the current state. A scheduled, recurring lookup tells you whether that state is changing -- and change, for a domain you're not actively expecting to modify, is usually the thing worth knowing about quickly rather than discovering weeks later.

Deciding what to include

Start with anything where an unnoticed change would actually matter: production domains and their key subdomains, domains tied to email deliverability, and anything on a security watchlist. There's little value in scheduling a check for a domain nobody would act on a change to -- the goal is a signal you'll actually respond to, not a comprehensive log nobody reads.

Picking a cadence

What to do with the results

The job itself is only half the value -- the other half is what happens when a run's results differ from the previous one. At minimum, keep enough history to compare consecutive runs (this tool retains job run history for a configurable retention window specifically for this reason). Exporting each run's results as CSV or JSON makes it straightforward to diff programmatically, rather than relying on someone noticing a change by eye in a dashboard they may or may not check that day.

Once a schedule is running reliably, the practical effect is turning DNS monitoring from an occasional manual task into a background process that only demands attention when there's actually something to look at -- which is exactly the point.

Designing the alert, not just the check

A scheduled check that notifies on every single run -- even the runs that found nothing new -- trains people to ignore it within a couple of weeks, which defeats the entire purpose. The useful signal is change specifically: this run's resolved addresses differ from last run's, a domain flipped from resolving to failing (or the reverse), or a new address landed in a range that shouldn't be reachable at all. Building the notification around "what changed since last time" rather than "here's today's result" is what keeps the alert worth opening months later, instead of becoming another unread label in an inbox.

What happens when the check itself fails

A scheduled job needs a plan for its own failure, not just for what it finds. If the job can't run at all -- a queue backing up, a worker process crashing, the underlying infrastructure it depends on going down -- that's a distinct, higher-priority signal than any individual domain's result, because it means the safety net itself has gone quiet without anyone necessarily noticing. A simple, separate "did the job run at all in the expected window" check, alerting if a run is overdue, closes this gap; otherwise a monitoring system that silently stops monitoring is arguably worse than having no monitoring at all, since it creates false confidence that everything is still being watched.