Internet down, business at a standstill: When a second connection makes sense

Emails won't load, Teams won't connect, the phone system goes silent. The server in the office keeps running, but a large portion of work now depends on the internet connection. When you call the provider, you might get a trouble ticket number. There's no guarantee when service will be restored.

A second line can reduce this dependency. But it's not automatically a functioning failover solution. What matters is whether it remains accessible when the problem occurs and whether the required applications can work over it.

First clarify what must keep running

Not every business needs the same performance in case of a failure. For email and a cloud-based business application, a smaller backup connection might suffice. Multiple video conferences, large file transfers, or a location with many employees create different requirements.

That's why planning begins with a short list: Which activities cannot tolerate longer interruptions? How many people need to perform them simultaneously? Can a large upload wait? Does an application need to remain accessible from outside?

These questions prevent decisions based on the price of a second connection without first defining the actual goal. A cheap backup connection that cannot support the critical application is still poor value for this purpose.

Two contracts don't necessarily mean two independent paths

A different provider name on the invoice doesn't prove technical independence. Two connections can use the same building entry point, the same cable route, or a shared upstream provider. If exactly that section is damaged, both may be affected.

A combination of fixed-line and mobile broadband creates a different type of backup route. It's also not completely independent: power supply, radio coverage, and regional network disruptions remain relevant. The goal therefore isn't the promise "can never fail," but a clearly understood separation of the most likely causes of failure.

Ask about the actual connection path before ordering. And test mobile coverage where the router will later be located. Good reception at a window on the upper floor tells you little about the planned location in the server room.

Failover is a function, not proof in itself

Many firewalls can manage multiple internet connections and switch to a backup route if one fails. To do this, they must determine whether a connection is actually usable. Simply checking the connection to the local modem isn't enough if the problem lies beyond it. With pfSense, for example, monitored gateways and defined failover rules are used. Manufacturer documentation on gateway monitoring.

A failover can interrupt existing connections, for example because the public IP address changes. An active call or VPN session may need to be re-established. Automatic failover therefore doesn't mean every application continues without noticeable interruption. Notes on Multi-WAN strategies.

Also check failback. An unstable primary line must not cause the connection to constantly jump between both routes and repeatedly interrupt work.

Mobile broadband has its own limitations

A mobile broadband connection can work very well as a reserve. But first, you should verify data volume, possible throttling, upload performance, and coverage under realistic conditions. For incoming connections, you also need to clarify what public accessibility the plan offers. A standard mobile internet connection doesn't automatically replace a connection with a dedicated public address.

During a failure, critical applications should take priority. Large cloud backups or downloads can wait if they would saturate the backup route. This requires a deliberate policy, not just a plea that nobody watch videos now.

Uninterruptible power supply is only useful to the extent it covers everything needed. If the firewall stays on but the fiber modem loses power, you still have no connection. When planning for an outage at the site, the entire required connection path must be considered.

The most important step is the controlled failover test

Schedule a maintenance window and deliberately interrupt the primary connection. Then test email, telephony, business applications, and remote access. Note how long the failover takes and which sessions need to be restarted. Then test the return to the primary line the same way.

A single successful website visit isn't enough. The test must match the activities that actually sustain operations. After changes to firewall, plan, or telephony, these checks should be repeated.

Conclusion

A second internet line makes sense when the consequences of failure justify the additional effort. Its value lies not in the second contract number, but in proven continued operation. Those who clarify dependencies, capacity, and failover beforehand know in an emergency what still works. This certainty is exactly what the solution should provide.

Would you like to review your internet failover arrangements? Talk to shinpo IT.