DNS Check watches its own infrastructure with several layers of monitoring, including DNS Check itself and third-party uptime monitoring services. One of those vendors polls a private health endpoint on our servers every five minutes, from probes around the world. That endpoint runs a set of internal checks (disk space, mail delivery, background job queues, DNS resolvers, and more) and returns an error if any of them fail. If it errors or stops responding, the vendor alerts us.

On October 20, 2026, that vendor stopped checking. It didn't send an alert or show an error, and nothing on its public status page covered the gap. Polling just stopped and didn't return for 27 hours.

We found out about an hour after it started, because we don't take the vendor's silence as good news.

What Happened

Our logs show the vendor's probes polling the health endpoint steadily, 12 times an hour from a pool of roughly 180 IP addresses across several cloud providers. Then they stopped:

Event Time (UTC)
Last poll from the vendor October 20, 06:02
Our "health endpoint unpolled" alert fires October 20, 07:05
Another vendor starts polling the health endpoint, restoring full redundancy October 20, 23:36
The original vendor's polls resume October 21, 09:20

That's 27 hours and 18 minutes without a single check from the vendor. When the polls resumed, they came from the same pool of IP addresses and at the same five-minute interval as before, as if nothing had happened.

DNS Check was never unmonitored. Our other monitoring layers kept running, but we lost one without warning, and if we hadn't been watching, we wouldn't have known one of our safety nets was gone.

Why We're Not Naming the Vendor

The vendor is still recovering from a difficult week, and pointing at them while they're in the middle of it wouldn't help anyone. Any monitoring service can go quiet, whether due to an outage, a bad deploy, a billing glitch, or a precautionary shutdown. The lessons here apply no matter which vendor you use.

How We Noticed

The health endpoint counts every poll it receives. Once an hour, a scheduled job on the server checks whether any polls arrived in the previous 60 minutes. If none did, it emails us (details removed):

No polls have reached the [health] endpoint on [host] in the last hour. [Vendor] has likely stopped monitoring this host (account lapse, misconfiguration, or a [vendor] outage). Verify that the monitor is up and still pointed at this host.

That makes the monitoring reciprocal. The vendor watches our server, and our server watches the vendor. Neither one can fail silently without the other one noticing.

The alert fired at 07:05 UTC, 62 minutes after the last poll. After confirming the endpoint was healthy, we pointed another vendor's probes at it, restoring the redundancy we had before the first vendor went quiet.

What We Learned

The alert worked, but this incident exposed a blind spot. It counts polls from any source. As soon as the other vendor started polling, the alert went quiet, and we lost visibility into whether the original vendor had come back. We only learned it had resumed by reading the server logs.

The fix is to track each vendor separately: give each one its own health check URL, and alert when any single vendor stops polling, not just when all of them do.

Lessons for Your Own Monitoring

  1. Silence isn't the same as health. Most monitoring setups only alert when a check fails. If the checks stop running, nothing fails, and you get no alert. Make sure something notices when your monitoring stops reporting entirely, not just when it reports a problem. This is often called a dead man's switch or heartbeat check.

  2. Use more than one vendor. A second, independent monitoring service turns a silent vendor outage into an inconvenience instead of a blind spot. Choose vendors running on different infrastructure, so a single cloud provider outage can't take out both.

  3. Watch each monitor individually. Redundancy can hide failures as easily as it catches them. If two vendors feed one alert, losing one of them looks the same as nothing happening at all.

  4. Don't rely on the vendor's status page. A vendor's status page reflects what it knows and chooses to report. Your own logs show what actually happened from your side.

  5. Use more than one notification channel. A monitoring service that checks correctly but can't send email is just as silent as one that doesn't check at all. Route critical alerts to at least two channels, such as email plus a chat app or a webhook.

The Same Applies to DNS

DNS is an easy-to-overlook dependency until it fails. If your uptime monitor resolves your hostname through public resolvers, a DNS problem can show up as a vague "site down" alert, or not at all if the resolver is serving a cached answer. Monitoring your authoritative DNS servers directly tells you what's actually published, independent of any one resolver or monitoring vendor.

DNS Check can monitor your DNS records alongside your existing uptime monitoring system. You can even have your uptime monitor poll the DNS Check API. This gives you an alternate notification mechanism if DNS Check can't reach you. It can also alert you if DNS Check's services go down.

A Note on This Week's PHP Vulnerabilities

On October 21, the PHP project announced two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that can allow unauthenticated remote code execution, and some services went offline as a precaution while they patched. DNS Check isn't affected: none of its services use PHP, so nothing needed patching, and there was no reason to take anything offline. If you run PHP anywhere, update to the fixed releases (8.5.12, 8.4.27, 8.3.36, or 8.2.35) as soon as you can.