Your site can be perfectly healthy on its servers while the world fails to find it. DNS is the phone book. When the phone book lies or disappears, HTTP uptime checks light up red and everyone debugs the wrong layer for twenty minutes.
What HTTP checks already catch
If api.you.com stops resolving, your HTTPS monitor will fail. You will get paged. That is good. The page will often say "timeout" or "connection error," not "NXDOMAIN" or "wrong A record." On-call SSHs into the app while the problem is a registrar lock, a deleted record, or a provider outage.
So HTTP monitoring is necessary and incomplete.
When a dedicated DNS check is worth it
Add one if:
- You change DNS more than rarely (migrations, failover experiments).
- You use DNS-based routing or multiple origins.
- You have already lost an hour to "the site is down" that was really nameservers.
- Enterprise customers depend on a stable hostname you do not control tightly.
A DNS monitor asks: does this name resolve to what we expect, from the public internet, on a schedule? Some tools check record values; others only that resolution succeeds. Either beats discovering the issue from a pile of identical HTTP failures.
What to watch first
- Apex /
www apior app hostname customers hitstatusif customers use it during incidents
Leave the long tail of marketing microsites alone until the critical set is quiet.
HTTP(S) consensus checks (what Tallwatch focuses on today) still catch customer-visible breakage when DNS dies. You may need provider status pages and dig in the runbook to classify it fast. Dedicated DNS monitors are a good complement from whatever stack you already use for DNS, or from a tool that ships that check type.
The decision rule: if DNS mistakes are in your top incident causes, monitor DNS on purpose. If not, keep sharp HTTP checks and a runbook step that says "check resolution before restarting the app."