A client’s internet went down on a Tuesday morning. Nobody called us about it.
Not because nothing was wrong — a regional fiber cut had taken out the primary circuit for hours. Nobody called because, from inside the office, nothing looked different. Email worked. The shared drive worked. Video calls worked. The office’s router had automatically failed over to a backup internet connection the moment the primary line dropped, and kept working right through the outage.
That’s the failover doing exactly what it was built to do. It’s also exactly how a real problem can sit invisible for days.
Why “it’s working” isn’t the same as “nothing’s wrong”
Most network monitoring checks one thing: can I reach the device? If the router answers a ping, it’s marked healthy. That’s a reasonable check — right up until a dual-WAN setup makes it the wrong question.
A router configured with a backup internet connection is designed to hide outages from the people using it. That’s the entire point — nobody wants a five-minute internet blip every time the primary carrier hiccups. But it means the router itself stays fully reachable the whole time it’s running on the backup line. Standard device-level monitoring has no way to tell the difference between “everything’s fine on the primary connection” and “we’ve been quietly running on a backup circuit since 9am.”
We only found out about the fiber cut because we went looking, after noticing something else during the postmortem: a handful of unrelated monitoring agents at other sites on the same regional carrier had also dropped offline around the same window. That’s what should have triggered an alert on its own — not require us to notice a pattern across sites after the fact.
The real risk isn’t the outage — it’s not knowing about it
A failover that works perfectly still leaves a business running on its backup connection, usually with less bandwidth and a different reliability profile than the primary line it was never meant to fully replace. If that backup connection also runs into trouble — and backup connections do fail, precisely because they get exercised far less often than the primary — there’s no fallback left. And if nobody’s monitoring which connection is actually carrying traffic, nobody finds out until the second failure, when everything actually stops.
There’s a quieter cost too. A backup circuit silently carrying business traffic for hours is a good moment to confirm call quality, file sync speed, and anything bandwidth-sensitive are still holding up — because “the internet works” and “the internet works well enough” aren’t guaranteed to be the same statement on a lower-tier backup line.
What actually closes the gap
Device-level “is it reachable” monitoring isn’t wrong, it’s just answering a different question than the one that matters for a failover setup. What’s needed is interface-level visibility: which WAN connection is actually carrying traffic right now, and has that changed recently. That means polling the router’s own status directly, not just pinging it from outside, and alerting the moment either interface goes down or which one is active changes — not waiting for a second failure to notice the first one ever happened.
For this client, that gap is closed now: a dedicated check runs every five minutes against the router’s local status, and a failover event triggers an alert the moment it happens, not after someone stumbles onto it. The next fiber cut in that region won’t be a quiet non-event — it’ll be a five-minute notification and a confirmed “yes, the backup’s holding, here’s what it’s actually running like.”
If your office has a backup internet connection, ask this
- Would anyone actually know if you were running on the backup connection right now?
- Does your monitoring check which WAN interface is active, or only whether the router responds?
- When was the backup connection last actually carrying real traffic — and did anyone check how it performed?
A failover you can’t see working is only half a safety net. The other half is knowing it’s working, the moment it starts.