Most businesses think they have failover. The day the primary line drops, they discover they don't. Here's the difference between a checkbox and a system that actually works.
By Jonathan Eubanks · May 26, 2026 · 9 min read
‹ Back to Blog Business Continuity · Internet & Network
By Jonathan Eubanks, Buckeye Telecom · May 26, 2026 · 9 min read
A manufacturer in Marion called us last fall. Their primary fiber circuit had been down for forty minutes. The “automatic failover” they were paying $480 a month for had not kicked in. Three shipping doors were idle. The phones were ringing into a recording. Their IT manager was on hold with the carrier, listening to the same hold music his calls were being routed into.
He told me, “We have failover. We just don’t know why it’s not working.” I told him what I tell almost every customer in that situation. He didn’t have failover. He had a box and a contract that mentioned failover. Those are not the same thing.
Most businesses think they have failover. Most businesses don’t, in the sense that matters. The line item on the invoice is there. The router has two WAN ports. The carrier’s portal shows green. And then the day a backhoe finds a fiber line, or a regional POP burps, or somebody’s promotional pricing expires and the secondary gets quietly shut off for non-payment, the failover that was supposed to save the operation does nothing of the kind.
Real failover is not a product. It is a system. And the system has five parts. If any one of them is missing, you are paying for an idea, not a result.
The first part is the easiest to get wrong, because everyone who sells it tells you it’s already done. “Diverse path.” “Redundant route.” “Carrier-grade redundancy.” The words are on every proposal. The physical reality almost never matches.
Logical diversity — two separate circuits on the carrier’s portal — is what most “failover” setups actually have. The two circuits enter your building through the same conduit, ride to the same regional aggregation point, and share the same long-haul corridor. A single backhoe takes both of them down at the same time. A single regional event takes both of them down at the same time. You bought two paths. You got one path with two account numbers.
Real physical diversity uses fundamentally different transport. Fiber primary and fixed-wireless secondary. Fiber primary and bonded LTE secondary. Two carriers whose entrance facilities you have personally verified come into the building from different sides. The cost is not significantly higher than buying two circuits from the same carrier. The reliability difference is the entire point.
What to look for. Pull the maps. Ask the primary carrier where their fiber enters your building and where it goes from there. Ask the secondary the same question. If the two answers describe the same corridor, you have a problem your contract does not acknowledge.
Quick win: Walk the exterior of your building this week. Find the carrier handhole or the meet-me point. If you cannot find two of them on different sides of the building, you do not have physical diversity yet — regardless of what the contract says.
The second part is what most people picture when they hear the word “failover.” It is also the part most often implemented in a way that doesn’t work.
The bad version: the primary goes down, the IT manager gets a Slack notification at 9:47 a.m., drives across town, plugs in the backup modem, and restarts the firewall. By the time the secondary is online, the outage is 35 minutes old, the warehouse missed a shipping window, and somebody is writing apology emails. That is not failover. That is a disaster-recovery procedure with a stopwatch attached to it.
The good version uses an SD-WAN appliance or a dual-WAN router with BGP-style failover. The primary drops, the device detects loss of signal within seconds, traffic shifts to the secondary, and applications continue running. Most users don’t notice. The ones who do see one stuttered Teams call before everything settles. Total cutover time: under thirty seconds.
The hardware to do this is not expensive. A capable SD-WAN edge runs five to eight thousand dollars at most sites, often less. A managed dual-WAN router is a few hundred dollars plus a service plan. What is expensive is the version where you skip this part and find out, the morning of the outage, that “failover” meant “we’ll be there in an hour.”
What to look for. Ask whoever set up your network how long the cutover takes. If the answer involves a person, the answer is too long. If the answer is “we’ve never tested it,” you have the same problem as the manufacturer in Marion.
The third part is the one nobody thinks about until they are sitting in the middle of an outage with no way to see what’s going on.
When your WAN is down, your remote-management tools are also down. Your SD-WAN controller in the cloud can’t reach the box on your network. Your firewall console is unreachable. Your monitoring dashboard shows everything red because it can’t see anything. The IT manager is now relying on phone calls from the front desk to figure out what’s working and what isn’t, which is exactly the wrong moment to be operating with bad information.
Out-of-band management is a small LTE modem that talks to the firewall or SD-WAN box on a separate channel — its own SIM, its own data plan, its own connection to the cloud. When the primary and secondary WAN are both unreachable for any reason, the management plane stays up. You can see the device status. You can see why the failover did or didn’t fire. You can push a config change. You can answer the CFO’s question in real time instead of “I’ll let you know when I know more.”
It is the part of failover nobody sells you on the proposal because it doesn’t have a sexy line item. Add it. It is the difference between operating an outage and being operated by one.
A free network resilience audit walks every site, maps the physical path of every circuit, tests the cutover, and tells you in plain English what would happen if your primary went down right now. No obligation. We’re not on a single carrier’s quota.
The fourth part is the one that separates failover that works from failover that worked, once, two years ago, the day it was installed.
A network changes constantly. Firmware updates. New SaaS dependencies. Cloud routes that used to fail open and now fail closed. A SIP carrier that quietly migrated its SBC pool. A VPN concentrator that the team rebuilt in March. Any one of those changes can break the failover that worked the last time you tested it, and you will not find out until the day you need it.
The fix is a recurring scheduled test. Once a month, on a Tuesday afternoon, somebody disconnects the primary WAN at one site for fifteen minutes. The secondary is supposed to take over. Document what happens. If the cutover is clean, log it and move on. If something fails — VPN drops, MFA flakes, phones don’t follow, a SaaS app times out — that is exactly the kind of thing you want to discover on a Tuesday afternoon with the team available, not on a Friday at 5 p.m. with a customer on the line.
Most businesses I work with have never tested their failover. Of the ones who have, a meaningful percentage discovered something broken on the first test. Every one of those discoveries was a hidden outage that would have shown up on the worst possible day instead.
What to look for. Put the test on the calendar this month. Schedule it for the same Tuesday every month. Treat it like the fire drill it is.
The fifth part is the one almost no carrier setup will mention, because it isn’t theirs to fix.
Your circuits can fail over perfectly and your business can still be down, because the failure was upstream. A DNS record with a 24-hour TTL means that even after your secondary is up and answering on a new public IP, the rest of the world still thinks you live on the old one. A cloud-hosted PBX with a single SBC in a single region goes dark when that region has a thermal event in Northern Virginia. A VPN concentrator that only lives on the primary side never makes the trip when the primary is down.
Working failover includes the cloud side of the picture. DNS TTLs short enough to follow a real cutover. Critical SaaS applications either inherently multi-region or with a documented local fallback. A VPN architecture that fails over with the rest of the WAN. A SIP carrier with geographically diverse SBCs. None of these is expensive on its own. All of them get missed because they don’t show up in the network diagram the carrier draws.
This is the part of a real audit that takes the most time and surfaces the most surprises. It is also the part that, when you fix it, makes the difference between “we have failover” and “we have failover that actually works.”
Quick win: Pull the DNS TTLs on your three most critical public records (web, mail, VPN endpoint). If any of them is over 300 seconds, that’s your first homework assignment. Short TTLs are free. Long TTLs cost you the first hour of every cutover.
Failover is not a product line. It is a system with five parts: physical diversity, automatic cutover, out-of-band visibility, scheduled testing, and a cloud-side picture that matches the on-prem picture. Any one of them missing turns the line item on your invoice into a story you tell after the outage instead of a system that prevents it.
The good news is that none of this is technically hard, and almost none of it is expensive relative to the cost of an outage. A real failover design at a typical Ohio multi-site business runs less than the loaded cost of two hours of downtime — once. The reason it doesn’t get done is not budget. It is that nobody on the carrier side is paid to walk your network and tell you the truth about it.
If you want to find out what your failover would actually do this afternoon, call us. Two of our engineers will walk your sites, map the physical paths, test the cutover, look at the cloud side, and hand you a plain-English picture of what you have and what you don’t. Free. No obligation. We don’t resell a single carrier’s product line, so the answer you get is shaped by what’s true, not by what’s on quota.
Call +1 (614) 224-2003. We’ll do the walk this month.
— Jonathan
Looking for help with this? See our page on Columbus business internet procurement.
Jonathan founded Buckeye Telecom in 2003 after years in the Columbus telecom industry — first at 5-Star distributors learning the carrier side, then carrying his own quota in telecom sales. He still works directly with clients — backed by the Buckeye team.
Talk to the Buckeye team — the owner is involved in every engagement, and there’s no advisory fee.
Prefer to talk now? Call or text 614-224-2003.