A backup connection only protects the business if the network can recognise the primary route has failed and switch traffic over fast enough.
That is not always straightforward. A circuit can be degraded enough to disrupt users without appearing completely unavailable to the network, preventing an automatic failover and leaving IT teams to intervene manually.
Greg LaBrie, VP and General Manager at WEI, describes this as a connection being “sick but not dead”.
“An outage of a primary connection oftentimes did not seamlessly transition over to the backup,” LaBrie told UC Today.
The result is that organisations can have redundancy in place but still face downtime while teams validate the fault, force traffic onto a secondary path and work to restore users.
Restore Users Before Fixing the Primary Circuit
LaBrie’s experience of managing network environments before joining WEI highlighted how easily a backup plan can become a manual recovery process.
In one role, primary and backup connectivity were in place alongside Cisco networking equipment and monitoring tools. But a primary connection did not always fail in a way that automatically triggered the secondary route.
A circuit could be impaired by routing issues or other problems without the physical connection going down. In those circumstances, the router might continue to treat the path as viable even while users were unable to access the services they needed.
The immediate priority was therefore not to diagnose and repair the primary connection. It was to establish which circuits were affected and restore users through the backup path.
“The first thing that we would do would be to validate which specific circuits were impacted and then immediately try to get the backup working,” LaBrie said.
That approach puts business continuity ahead of root-cause analysis. Once the backup connection is active, IT teams can investigate the primary route, work with the relevant provider and arrange a controlled switch back when it is safe to do so.
During an outage, teams could receive alerts at the same time as employees began reporting that the network was not working. Engineers might need to access a router, check the circuit state and force the primary interface down before the backup connection would take over.
That is a labour-intensive process at precisely the moment an organisation needs speed and clarity.
The Commercial Reality of Failover
Backup connectivity can also introduce a difficult commercial decision.
LaBrie said organisations may choose lower-cost backup options that incur charges when used. In an incident, IT teams can find themselves weighing the cost of activating a backup service against the impact of leaving users without connectivity.
“I know I can do backup, but does the company want backup now at $5 a minute or $10 a gigabyte or whatever it is that you were having to pay for that usage?” he said.
That decision needs to be made before an incident, not during one.
Organisations should understand how their backup connectivity is priced, who has authority to activate it and which services or groups of users should take priority. If a backup link is expensive or capacity-constrained, the business must decide in advance whether it is intended to support every workload or only critical operations.
The cost of backup capacity should also be weighed against the impact of downtime. A connectivity outage can affect employees, cloud applications, customer-facing services and operations across branch locations. The price of using an alternative route may be easier to justify when the operational consequences are clear.
Runbooks should set out escalation paths, decision-makers and technical steps, so that the response is not held up by uncertainty over spending or responsibility.
