PingArmor's 5 failover rules and how long failback takes

The other two posts about failover explain the concept: what automatic failover is and how the tunnel keeps your game alive during the switch. Here we go one step further: the exact rules of each failover type, how long each one takes, when PingArmor decides to return to your primary internet — and how to follow all of it in real time inside the app.

Transparency is the goal. When a switch happens, you don’t have to guess what’s going on: you can read it on screen and, if you want, get a notification in the Windows tray.

The 5 failover triggers

PingArmor monitors your primary internet all the time (a test every 750 milliseconds) and the latency to the game servers (every 1 second). Based on that, five different situations can trigger a switch to the secondary internet. Each one has its own rule and its own reaction time:

#	Type	What happened	Time to switch
1	Down (offline)	The primary interface vanished — cable unplugged, adapter disabled, no link and no IP	~1-2s
2	No response (drop)	The ping to the router and the internet test fail at the same moment	~1-2s
3	Dead connection (TCP-dead)	The router responds, but there’s no real internet — hotspot out of data, public Wi-Fi login portal	~1.5-2s
4	Router lag	The ping to your router goes over the threshold (default 150ms) for 3 readings in a row	~2.5-3s
5	Game lag	The real latency to the game servers goes over the threshold	~8-19s

The 150ms (failover) and 80ms (failback) thresholds are configurable in the preferences — the rest of the rules are fixed in the product.

One safety lock applies to all five: if the secondary internet is unavailable, no failover happens. PingArmor never throws you onto an interface that’s also dead — it’s better to hold on the primary than to fall into a network that doesn’t exist.

Why “game lag” is the slowest

You may have noticed: trigger #5 takes 8 to 19 seconds, much longer than the others. That’s on purpose.

Game latency is the signal most prone to false alarms. An isolated ping spike, a weird reading from an idle connection, the game server taking a while to answer an unimportant packet — none of that means your internet is bad. If PingArmor switched interfaces on every spike, you’d live in a constant back-and-forth for no reason (the infamous flapping), and every switch has a cost.

That’s why #5 requires a window of real, sustained readings above the threshold before acting. It only switches when it’s sure the lag is genuine and persistent — not a ghost. Triggers 1 through 4 are about your local connection (cable, router, internet) and are unambiguous, so they act fast. #5 is about the route to a distant server, it’s ambiguous, and that’s why it’s patient.

When PingArmor returns to the primary (failback)

Switching to the secondary is the easy part. Returning to the primary — the failback — is where the intelligence lives, because returning too early throws you right back into the problem that caused the failover.

PingArmor only performs the failback when all of these conditions are true at the same time:

1. The primary is healthy again — ping to the router below the failback threshold (default 80ms) for consecutive readings.
2. The wait has passed — a 15-second cooldown since the failover.
3. The game is fine — the latency to the servers is back to normal (or a 2-minute limit has been reached).
4. The internet is real and stable — the real connection test passes consistently, not just for an instant.

In practice, two scenarios:

• Cable was out for more than 15 seconds (the cooldown already ran while it was out): the failback happens ~3 seconds after the link comes back.
• Cable came back quickly (replug within a few seconds): PingArmor waits the full 15s cooldown before returning.

Failback is intentionally more cautious than failover. Switching to the secondary solves a problem now; returning to the primary too early creates a new one.

When the primary keeps dropping: the wait doubles

What if your primary internet stays unstable — drops, comes back, drops again? PingArmor has an anti-flapping brake.

If a failback happens and right afterward (within 15 seconds) the primary fails again, that’s a bounce. With each bounce, the wait time doubles: 15s → 30s → 1min → … up to a ceiling of 5 minutes. The more the primary proves it’s unstable, the longer PingArmor waits before trying to return — protecting you from a string of switches.

When the primary finally stays stable for 2 minutes straight, the counter resets and the wait goes back to the default 15 seconds.

This shows up on screen as a 2x, 4x indicator next to the countdown — and, if you turn notifications on, as a “Return delayed” alert in the tray.

Follow the failback in the “NETWORK INTERFACES” card

When a failover is active, the NETWORK INTERFACES card gains a new line: FAILBACK, with the countdown until the next attempt to return to the primary. No guesswork — you see exactly how much is left.

The dot on each interface tells you everything: green = active and healthy, yellow = active but it’s the secondary, gray = on standby, red = offline. In the example above, the primary (Ethernet) is already back and on “Standby” while the 12-second cooldown runs; the secondary (Ethernet 3, a 4G connection) stays active for now.

The FAILBACK line changes color and text depending on the situation. There are four states:

• Yellow countdown (0:12) — the normal cooldown running. When it hits zero and everything is fine, PingArmor returns to the primary.
• Red countdown + 2x — the wait was doubled because the primary has been unstable (the backoff explained above). The number next to it shows how many times.
• WAITING TO STABILIZE (blue) — the cooldown is over and PingArmor is doing the final checks (is the primary really stable? is the game back to normal?) before performing the return.
• WAITING FOR PRIMARY (yellow) — the primary interface is still physically offline (cable out). There’s no countdown because there’s nothing to count: the failback only starts when the primary exists again. As soon as the link returns, the state turns into a normal countdown.

Windows tray notifications (optional)

By default, all of this control is silent — it happens on its own while you play. But if you want to know the moment a switch happens (without having to look at the app), you can turn notifications on.

In the gear → Settings, in the preferences card, check the “Notify failover in the tray” box:

With this on, you get a balloon at three moments — exactly the three states the card shows:

• Failover active — failover kicked in; it already shows the estimate of when it should return.
• Return delayed — the primary bounced and the wait doubled (the 2x on the card).
• Back on the primary network — failback complete, everything normal again.

The option ships off by default because most people prefer the protection to be invisible. Turning it on or off changes nothing about how failover behaves — it’s only about getting (or not getting) the notification. Check it, save, done.

Summary

Question	Short answer
How many failover types are there?	Five: down, no response, dead connection, router lag, game lag
Why does game lag take longer?	So it doesn’t switch needlessly on a false ping spike
When does it return to the primary?	Primary healthy + 15s cooldown + game OK + stable internet
What if the primary keeps dropping?	The wait doubles (up to 5min); resets after 2min stable
Can I watch it happen?	Yes, on the FAILBACK line of the NETWORK INTERFACES card
Can I get notified?	Yes, opt-in: “Notify failover in the tray”

All of this runs on its own — you don’t need to configure anything beyond choosing the two interfaces. Failover and failback happen automatically; the card and the notifications exist only to give you transparency about what PingArmor is doing for you.

Want the big picture before diving into the details? See what automatic failover is and how PingArmor protects your game during the switch.

Try it free for 3 days — no credit card.