Two Circuits Are Not a Redundancy Design

August 22, 2026

A second internet connection is not automatically a resilient design. If both paths share a riser, a firewall, or a power feed, you bought two invoices and one failure. Business internet redundancy starts with what must keep working, then how traffic moves, then who tests it.

That is why the live redundancy and failover requirements worksheet asks for business impact, failure domains, and failover behavior before you compare circuits. This post does not replace that page. It is a supporting note on why "add a backup" is not the requirement.

What the public training is actually about

A Telarus HITT session (February 26, 2026) on network bundling treats a second path as operational insurance, not an upsell. The published talk uses a retail fiber-cut example: neighbors went dark while a cheap cellular backup kept a store working. It also uses a four-hour outage example for a small office. Those numbers and the "bundle" sales frame are theirs, not ours.

Use it as a requirements example only: write down how long the site can be offline, which apps must survive, and whether the backup path is actually independent. It is not a Data Partner engagement, not a TDP win, and not a Verizon or cellular product pitch.

What to add to the worksheet

Before a quote, fill these rows:

Business impact: what stops (payments, voice, cloud apps, building systems) and for how long that is acceptable.
Failure domains: last mile, building entrance, power, edge device, DNS, identity. Different brand names do not prove diversity.
Failover behavior: what trigger moves traffic, what stays on the backup path, and whether failback is automatic or a change window.
Security on the alternate path: inspection, logging, and access still apply, or you built an unmanaged hole.
Test owner: who runs a controlled failover, how often, and where the result is written.

If SD-WAN is in the mix, keep it honest. Overlay policy does not replace underlay diversity. The SD-WAN provider evaluation is the companion, not a substitute for this worksheet.

Questions that belong in the first meeting

Ask the provider to show, not describe:

A map of shared failure domains, not two logos.
What the payment terminal or the voice path does in the first 30 seconds of a degraded primary.
Whether inbound services, public IPs, and allowlists survive the cutover.
Who gets the alert, and who opens the carrier ticket.
The last time a failover test was run, and what broke.

If they cannot show those, they are selling a second circuit, not redundancy.

What not to do

Do not treat a training deck as a TDP case study. Do not paste SMB downtime math, combo-meal bundling, or SPIFF language onto this site. Do not run Verizon Fios SMB Days as a TDP promo. Do not publish this draft as a win.

Write the worksheet. Then compare.