Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Failover is the automatic switch from a failed component to a ready spare. Here's where it lives in a small network, active-passive vs active-active, why failback is the hard half, and how to test it before it matters.
A second internet line or a second server only helps if something switches to it before anyone notices. That switch has a name, a few moving parts, and a long list of ways to go wrong. This guide explains what failover is, where it lives in a small network, and how to tell whether yours would work on a Tuesday afternoon.
Failover is the automatic move of a job from a component that has failed to a spare that is ready to take it. The job can be internet traffic, a firewall's sessions, a database, a virtual machine or a whole site. The spare can be a second ISP line, a second firewall, another node in a cluster or a copy of your servers in another building.
Three steps happen every time, whether the hardware is a $200 router or a hospital cluster. Something detects the failure: a heartbeat stops, a ping to a public address fails, a service stops answering. Something decides the failure is real and not a blip, usually by waiting for a set number of misses. Then something switches: a route changes, a virtual IP moves, a standby node takes ownership of the storage and starts the service.
Redundancy and failover get used as one word, and they're two things. Redundancy is the spare. Failover is the switch. You can own the spare and still have no failover, which is the most common shape of a "we have a backup line" setup. The line sits dark, and when the primary drops, a person drives to the office and moves a cable.
Each layer of a network has its own version, and they stack. The internet edge is the one worth doing first, because every cloud app, VoIP phone and remote session dies with it.
The pfSense walkthrough below shows the WAN layer end to end: two gateways, a gateway group, the monitoring IPs and the moment the primary gets pulled.
The two words describe what the spare does while nothing is broken.
| Active-passive | Active-active | |
|---|---|---|
| What runs normally | One side carries everything, the other waits | Both sides carry work at the same time |
| What happens on failure | The standby detects the loss and takes over | The surviving side keeps going with less capacity |
| Interruption | Seconds to a minute while the switch happens | Often none, sometimes slower service |
| Idle cost | A full spare doing nothing | No idle hardware, but each side must fit the whole load |
| Hard part | Keeping the standby patched and tested | Keeping data in sync between two live sides |
| Typical fit | Firewall pairs, WAN backup lines, file servers | Web front ends, load balancers, databases built for it |
Active-passive is simpler and it's what a small office usually runs. Microsoft's own failover clustering overview puts it the same way: active-passive trades resource use for predictability, active-active trades simplicity for throughput. The thing to size on an active-active pair is the day one side is gone, not the day both are fine.
Failback is the return trip. The fiber line comes back, the primary node is patched, the main site has power again. Something has to notice that and move the work home, and it's the half nobody designs.
On a WAN pair, failback is cheap: the gateway sees the primary answering pings again and prefers it. The catch is flapping. A line that comes and goes every few minutes will bounce traffic back and forth, and every bounce drops VPN tunnels and VoIP calls. Good routers add a hold-down timer so the primary has to stay healthy for a while before it gets the traffic back.
On servers and sites, failback is the expensive direction. Data written on the standby has to be copied back before the primary can lead again, which is why DRaaS providers schedule failback as a planned window rather than an automatic event. One r/opnsense user wrote up the full loop for a home-office firewall: wired ISP as primary, an iPhone hotspot as the backup WAN, automatic switch on loss, automatic return when the wire is back, and a cron job that re-raises the Wi-Fi interface when the hotspot times out. The write-up is long because the recovery half took more work than the failover half.
A failover setup that doesn't work on the day was rarely broken. It was built around an assumption that turned out to be false.
The link is up, the internet is gone. A router that watches link state sees the cable plugged in and a modem with lights on, so it never switches. The modem has lost its upstream. The fix is a health check that pings something past the ISP, such as a public DNS resolver, through each WAN, and fails over on that.
Two providers, one conduit. Separate contracts don't mean separate paths. A cable line and a fiber line installed months apart often enter the building through the same duct, and one digger takes both. Two ISPs that lease the same last-mile fiber fail together as well. Ask each provider how the circuit physically reaches you before calling it redundant.
The ISP wired both links as one. In the r/networking thread below, a team deployed a firewall HA pair with a fiber primary and a radio backup from the same ISP. The ISP bridged both links on its side and handed out one shared gateway for both, so bringing the backup port up caused a broadcast loop, and the modems dropped the spanning-tree frames that would have caught it. The only stable state was leaving the backup port shut down and bringing it up by hand. Redundant hardware, manual failover, until the ISP assigns a separate IP block.
The standby can't carry the load. An LTE backup that handles email fine will not carry forty VoIP phones and a VPN. A cluster node that was fine as a spare two years ago is now half the RAM of the production node. Failover works, and the office is unusable anyway. Size the spare for the worst hour, not the average one.
Uptime Institute's 2025 outage analysis found that 54% of respondents' most recent significant outage cost more than $100,000, and 80% of operators said better management and processes would have prevented it. Failover that was bought and never tested is exactly the kind of process gap they mean.
A failover that has never been triggered on purpose is a theory. Testing it is a short, repeatable exercise, and it belongs on the same calendar as your disaster recovery testing.
Pull the upstream, not the cable. Unplugging the WAN cable from the router tests link-state detection, which is the easy case. Unplugging the coax or fiber from the modem, or asking the ISP to drop the circuit, tests the case that happens in real life: link up, internet gone.
Time two things. Time to switch is how long traffic takes to move, and it should match what the thresholds promise. Windows Server clusters, for example, declare a node down after 10 missed one-second heartbeats on the same subnet and 20 across subnets, per Microsoft's cluster team. Time to notice is how long until a human knows the office is running on the backup. If the answer is "when the bill arrives", add an alert for the gateway change to your infrastructure monitoring.
Then test the way back. Reconnect the primary and watch whether traffic returns, how long it holds before switching, and what breaks on the return trip. VPN tunnels and VoIP registrations are the usual casualties on both legs. Write the results down with the date, because the next test will be compared against them.
If you run OpenFrame, a script across a site's devices that records each machine's current gateway and public IP is a cheap way to confirm failover moved everyone, not just the firewall.
Not every layer is worth the money, and the order matters more than the budget. Start where one failure takes everything down.
A second internet path on a gateway with real health checks is the first purchase for almost any office that runs on cloud apps, and an LTE or 5G modem on a different carrier is the cheapest second path. A firewall HA pair comes next for offices that host anything inbound, such as a VPN or a phone system. Server clustering is worth it when a single on-prem server carries the business, and only when the standby node is kept at the same spec and patch level. Multi-site failover, where a whole office moves to another building or to a provider, is a DRaaS or business continuity decision, not a networking one.
Failover is a switch, and a switch has to be thrown on purpose at least once before it earns the word. Put the second line in, point the health check past the ISP, and pull the modem's upstream on a quiet afternoon. If you're pricing what that afternoon protects, start with what downtime costs and work backwards. Next read: the small office network design checklist, which covers where the second WAN plugs in.
Content Marketing Lead
Ohayo! I run content, SEO, social, and community at Flamingo. Before IT, I worked as a correspondent for Ukraine's Public Broadcasting Company and have a Master's in journalism.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.
