A Running Monitor and 25 Domains It Never Looked At

We were about to move 25 domains, including the main one customers use every day, off an aging server and onto new infrastructure. Nobody’s mail or site could go down in the middle of it. We had no dedicated operations team, so we did it with a careful inventory of every domain’s pieces: where it points, what mail routes through it, and what has to move together so nothing breaks mid-swap.

The move itself went fine. It took roughly six and a half hours, twenty-five domains relocated, no outage, no lost mail. From the outside, that looked like the whole story.

The part that mattered came from checking whether the safety net under the move was real. Before flipping anything, we looked at what the existing health monitor was watching. That’s the thing that’s supposed to tell someone the moment a site goes down. It wasn’t watching the business’s live domains. It was watching a personal address and a couple of test domains, some of them expired, that had nothing to do with what customers were using.

The migration didn’t cause this. That monitor had been pointed at the wrong things for a while, and nobody noticed. A monitor that’s running looks the same from the outside whether it’s watching the right thing or the wrong thing. Green means green. It doesn’t say green for what.

What would have happened on a bad day

If one of those twenty-five domains had gone down mid-move, the monitor would have said nothing, because it wasn’t looking at that domain in the first place. The safety net we all believed existed didn’t cover the thing it needed to cover. That gap could have sat there indefinitely, waiting for a bad day to expose it. This migration only found it because we finally read what the monitor’s configuration actually said instead of trusting that it existed.

Fixing the order, not just the targets

The fix was about sequencing as much as repointing. We moved the monitor to the real, customer-facing domains only after the new routing was already verified to work. That order mattered. A green check on the old, wrong targets during the actual move could have been mistaken for real coverage at the exact moment coverage mattered most. Getting the order backward would have meant trusting a working-looking light on a system that wasn’t being watched yet.

A five-minute check

Having a monitor is a different claim from the monitor watching the right thing. Open whatever does your health checking today and read, literally, what addresses or systems it’s pointed at. Compare that list against what your customers actually use. If the two lists don’t match exactly, you have a gap that behaves like coverage until the day you need it.

Ask whoever runs your health monitoring for the list of addresses it checks, and compare it against the domains your customers actually use. Do that before any migration, and move the monitor to the real domains only after the new routing is verified.

dxdev LESSON · paste into your AI coding agent
LESSON: A monitor's existence tells you nothing about its coverage
WHAT TO SHARE: List every automated check, alert, or monitor your business relies on, plus what each one is actually configured to watch.
ASK YOUR AGENT TO:
1. For each monitor, state plainly what it is checking today versus what a person would assume it is checking, given its name or its purpose.
2. Flag any monitor pointed at a test address, an old address, or anything that isn't the live thing customers actually use.
3. Recommend, in order, how to move a monitor onto the right target without losing coverage during the switch.
RETURN: A table of monitor name, what it actually watches, what it should watch, and the gap.
BOUNDARY: Analysis only. No agent repoints a live monitor, disables an alert, or changes a production target on its own; a person approves the change and the order it happens in.