When should a small SaaS start monitoring DNS resolution separately from HTTP checks?

What an HTTP check tells you about DNS, and what it hides

Every HTTP check begins with a DNS lookup, so in a sense DNS is already being monitored: if the name stops resolving, the check fails. But the failure is reported as a generic connection error, and the check only sees the answer given by the resolver the probe happens to use. A resolver with a cached answer will keep succeeding for the duration of the TTL after your nameservers have already gone dark. Your monitor can report green for an hour while new visitors, whose resolvers have no cache, get nothing.

HTTP checks also cannot tell you what the answer was. If a record is silently changed to the wrong address, the check might still return a 200 from whatever server sits at that address, especially if it is a parked page or an old environment. And an HTTP check knows nothing about records it never uses: the MX records that carry your transactional email, the TXT records that authenticate it, the CNAME your status page depends on. All of those can break with zero effect on the homepage check.

Keep reading: How to Choose an Uptime Check Interval That Actually Catches Outages, Status Page Best Practices That Reduce Support Tickets, Uptime vs Response Time: What to Monitor and Why Both Matter. See how PingCrumb helps you uptime monitoring and hosted status pages.

The failures that only a DNS check catches

Nameserver outages at the DNS host are the headline case. When a DNS provider has an incident, every domain it serves becomes unreachable for anyone without a cached answer, and the affected company usually finds out from customers rather than from monitoring. A dedicated DNS check that queries your authoritative nameservers directly, bypassing caches, sees this immediately. Querying several public resolvers as well tells you how the outage is propagating and whether it is universal or regional. Related: How to Choose an Uptime Check Interval That Actually Catches Outages

The quieter failures are record drift and domain expiry. Someone edits a record while setting up a new service and overwrites the one that mattered. An automation renews a certificate and leaves a stale validation record that later collides with a change. A domain registered years ago under a former employee's card lapses, and the grace period runs out. A DNS check that asserts on the expected value of each record, plus a separate watch on the domain expiration date, catches these days or weeks before they become an outage. Related: SSL Certificate Expiry: How to Never Get Caught Offline

The point where separate DNS monitoring stops being optional

For a side project with one A record, the HTTP check is enough, and the missing piece is just a calendar reminder for domain renewal. The line gets crossed when any of the following are true: you send transactional email and rely on MX, SPF, or DKIM records; you use a CDN or a hosted service through a CNAME that someone else controls; you have more than one person with access to the DNS zone; or you have made a DNS change in the last year that you were nervous about. Each of those adds a way for DNS to fail that the homepage check will not report clearly.

A sensible starting configuration is small. Monitor the A or CNAME record for the main hostname against its expected value from at least two resolvers. Monitor the nameservers themselves by querying them directly. Monitor MX and the key TXT records if email matters to your product. Track the domain expiration date with alerts at sixty, thirty, and seven days out. That is a few minutes of setup, and it covers the large majority of DNS-related outages a small SaaS will actually meet.

How to respond when DNS is the thing that broke

DNS incidents are unusual because you often cannot fix them on your side quickly. If your provider's nameservers are down, the practical options are to wait, or to have a second provider already configured as a secondary and switch the delegation at the registrar. The second option only works if it was set up in advance, and the delegation change itself takes time to propagate. This is why DNS monitoring pairs well with a written plan: who has registrar access, where the credentials live, and what the fallback nameservers are. Related: Uptime vs Response Time: What to Monitor and Why Both Matter

Communicate differently, too. A DNS outage means your status page might be unreachable if it lives on the same domain, which is a strong argument for hosting it on a separate domain or a provider-owned subdomain. Tell customers to try again in a while rather than promising a fix time, since propagation is outside your control. Afterward, lengthen TTLs on records that rarely change so that caches carry you through the next provider incident, and shorten them temporarily before any planned migration. Related: Status Page Best Practices That Reduce Support Tickets