Pool Failover & Backup-Pool Configuration: A Practical Setup Guide

A backup pool is the difference between a brief stratum hiccup and hours of dead hashrate. This guide shows how to order primary, secondary and tertiary pools, how failover differs from quota load-balancing, which brand-safe redundancy choices make sense, and exactly where to configure it across stock Bitmain, BraiinsOS+ and AxeOS — plus how to catch a silent failover before it costs you.

Every miner eventually meets a pool that goes dark. A stratum server reboots, a regional endpoint drops, a DNS record goes stale, your ISP hiccups, or the pool schedules maintenance at the worst possible time. If your rig points at a single URL, that event means zero accepted shares until you notice and intervene. A correctly ordered backup pool turns the same event into a few seconds of reconnect that you might not even see in the daily numbers.

This is a setup guide, not a troubleshooting one. If your failover is already misbehaving — flapping between pools, looping, or never coming back — start with the companion pool-failover instant-fallback-loop diagnostic and return here once the rig is stable.

Why one pool is a single point of failure

Stratum is a long-lived TCP connection. When that connection breaks and cannot be re-established, the miner has nowhere to send work and your hashboards keep burning watts while producing nothing payable. Pools are remarkably reliable, but “reliable” is not “never,” and the failure modes are not all the pool’s fault:

• Pool-side: server maintenance, a DDoS event, an overloaded stratum node, or a region taken offline.
• Network-side: your ISP, a routing change, a flaky switch, or Wi-Fi on a device that should be wired.
• Config-side: an expired or rotated endpoint hostname, a typo, or a worker name the pool no longer recognizes.

A backup pool covers the first two cleanly and buys you time on the third. The cost is a few minutes of setup. The protocol itself is built for this: Stratum even defines a client.reconnect message a pool can send to migrate a miner gracefully, but failover is the safety net for when the pool cannot say anything at all. For the deeper protocol mechanics, see the Stratum glossary entry.

How failover actually works

The standard model is an ordered list of pool slots, tried top to bottom:

• Primary (Pool 1): where you want every share to go under normal conditions.
• Secondary (Pool 2): a genuinely independent backup — ideally a different pool operator, or at minimum a different stratum endpoint.
• Tertiary (Pool 3): a last resort. Many operators set this to a different region of the primary, or to a solo endpoint that will keep the hardware busy no matter what.

When the primary connection drops and reconnect attempts fail, the miner moves down the list to the next live pool and resumes hashing there. The behaviour that surprises people is failback — whether the miner returns to the primary once it recovers. This is firmware-dependent and version-dependent, so treat it as something to verify on your exact build rather than assume:

• Some firmware periodically re-probes the primary and switches back automatically when it returns.
• Stock Bitmain builds historically tend to stay on the working backup until the miner is restarted or manually re-pointed. If you care about returning to the primary, check the miner after any outage.

One clean trick: making Pool 2 an identical copy of Pool 1 (same pool, same credentials, perhaps a different regional hostname) guarantees the rig resumes on your intended pool after a single-endpoint blip, and only escalates to a truly different operator at Pool 3.

Failover mode vs quota / load-balancing mode

It is worth being precise, because the two are often confused. Failover sends 100% of your hashrate to the highest-priority pool that is alive, and only uses the others when that one is down. Load balancing (sometimes called quota or hash-distribution mode) deliberately splits your hashrate across multiple pools at the same time, according to weights you set.

For the overwhelming majority of readers, you want pure failover. Load balancing only earns its keep if you are intentionally diversifying which pool finds your blocks, and it complicates monitoring because “some” of your hashrate being on a pool is harder to alarm on than “all or none.” Keep it simple unless you have a specific reason not to.

Choosing brand-safe backup pools

A backup is only useful if it is genuinely independent of the primary. Putting two endpoints of the same pool in all three slots protects you from a single server dying but not from that operator having a bad day. The Bitcoin mining ecosystem gives you several well-regarded, censorship-resistant options to mix and match — each built on the shoulders of the operators and developers who came before. Verify the current endpoints against each project’s own documentation before you deploy; ports and hostnames do change.

A few notes that matter when these become your fallback, not your primary:

• Reward models differ. A shared pool pays steady, smoothed rewards; a solo pool pays nothing until you (improbably) find a whole block, then everything. If your backup is a solo endpoint, understand that a long stint on it means a long stretch of zero payouts even though the hardware is “working.” That is often an acceptable trade for never going fully dark — just go in with eyes open.
• Credentials differ. Solo endpoints (CKPool, Public Pool) take your on-chain BTC address as the username. Shared pools (Braiins, OCEAN) may take a pool account name. A backup slot filled with the wrong username format silently mines to nowhere useful. Test it.
• Self-hosting is the strongest backup. Public Pool is open source and runs against your own node — a self-hosted instance on your LAN is about as resilient and sovereign a tertiary as you can build, because it does not depend on anyone else’s uptime. See the solo mining guide for the wider picture.

For a structured comparison of operators, fees and policies, the mining pool comparison and the broader mining pools hub are the right starting points.

Configuring failover by firmware

The concept is universal; the field names and number of slots are not. Always enter the same correct payout credentials in every slot, then save and reboot if the firmware asks. The three sanctioned configurations below cover the vast majority of Antminer-class hardware and the open-source Bitaxe family.

Stock Bitmain firmware

The Antminer web interface gives you three pool slots — Pool 1, Pool 2, Pool 3 — each with a URL, worker and password field. Enter your primary in Pool 1 and independent backups in Pool 2 and Pool 3. These slots are strictly failover: the miner uses the highest-priority live pool and does not split hashrate. Enter the host as the pool documents it; most Bitmain builds accept either a bare host:port or a stratum+tcp:// prefix. After saving, open the miner’s status page and confirm Pool 1 shows as Alive with a non-zero accepted-share count. Remember the failback caveat above: after an outage, check that the rig returned to Pool 1 rather than camping on Pool 2.

BraiinsOS+

BraiinsOS+ (the successor lineage to the original Braiins/Slush mining stack) is more capable here. It organizes pools into pool groups. Within a single group, the listed pools behave as ordered failover — exactly the primary/secondary/tertiary model. Across multiple groups, you can assign a quota to each group to split hashrate (load balancing). For straightforward redundancy, use one group containing your primary and backups in priority order and ignore quotas entirely. BraiinsOS+ supports both Stratum V1 (stratum+tcp://) and Stratum V2 (stratum2+tcp://host:3336/<public-key>, where the public key authenticates the endpoint and blocks hashrate-hijacking). A pragmatic early-V2 pattern is a V2 primary with a V1 endpoint as the tertiary, so a V2-specific issue never drops you to zero. Pull the current V2 endpoint and key from Braiins’ own docs at deploy time — they now publish a single geo-routed global URL rather than regional hostnames. For protocol background, see our Stratum V2 explainer, and compare capabilities on the firmware feature matrix.

AxeOS (Bitaxe)

AxeOS — the open-source firmware from the Bitaxe community — exposes a primary stratum config plus a fallback stratum config. In the web UI you fill in Stratum Host, Stratum Port and Stratum User for the primary, and the matching Fallback Stratum Host / Port / User for the backup. Enter the host without the stratum+tcp:// prefix. If the primary becomes unreachable (community builds typically switch after a few failed attempts), AxeOS moves to the fallback automatically and periodically retries the primary, returning to it when it comes back. Because a Bitaxe is usually solo mining, a sensible pairing is one solo pool as primary and a second, independent solo endpoint as fallback so a block is still possible whichever one you are on.

Other firmware in the landscape (such as VNish, LuxOS or ePIC builds) implements its own failover too; the principles in this guide carry over, but always configure against that firmware’s own current documentation.

Geographic and endpoint redundancy

Failover is only as independent as the endpoints you choose. Pointing all three slots at the same physical region defeats the purpose if that region is what goes down. Most serious pools publish multiple geographic stratum endpoints — for example CKPool offers regional hostnames such as eusolo.ckpool.org, sgsolo.ckpool.org and ausolo.ckpool.org alongside the default. Use them deliberately:

• Primary: the endpoint geographically closest to your hashcenter, for the lowest stratum latency and fewest stale shares.
• Secondary: a second region of the same pool, or a different operator nearby.
• Tertiary: a far backup or a self-hosted instance that does not share infrastructure with the first two.

Watch latency when you fail over to a distant region: higher round-trip time raises your stale/rejected share rate, quietly shaving effective hashrate even though the miner reports “connected.” Acceptable as a temporary backup; a poor permanent home.

Detecting silent failover

The trap with good failover is that it works too quietly. Your rig keeps hashing, the lights stay green, and you never realize you spent three days on a backup pool — possibly a solo endpoint with a very different payout profile, or a slot with a stale worker name. Build a habit and a signal so failover is something you observe, not something you discover on payout day.

• Check which pool is active, not just that one is. Stock Bitmain status pages mark each pool Alive or Dead and show accepted shares per pool. AxeOS shows the connected pool in its dashboard. BraiinsOS+ shows the active pool and exposes metrics for scraping.
• Poll the miner API. Most Antminer-class firmware answers the cgminer-style API pools command, which reports each pool’s status and which one is “Stratum Active.” AxeOS serves a JSON system-info endpoint. A tiny script that reads this on a schedule and alerts when the active pool is not Pool 1 catches silent failover within minutes.
• Use pool-side worker alerts. Most pools can email or message you when a worker goes offline. Enable that on your primary — if the primary loses your worker but the hardware is plainly still running, you have failed over without knowing.
• Watch hashrate-per-pool dashboards. A drop to zero on the primary’s dashboard while your local rig still reports full hashrate is the unmistakable signature of a live failover.

Finally, test failover before you rely on it. Temporarily break the primary (block its port at your firewall, or set an intentionally wrong primary port) and confirm the rig lands on the backup, with your correct address, producing accepted shares — then restore the primary and confirm failback behaviour on your specific firmware. A backup pool you have never exercised is a hope, not a plan. Keep your monitoring habits sharp, and if a failover ever exposes a hardware fault on a board, the ASIC repair resources are the next stop.

A sane default ordering

If you just want a known-good recipe, this covers most home and small-hashcenter setups:

1. Pool 1 (primary): your chosen pool, nearest regional endpoint, correct credentials.
2. Pool 2 (secondary): the same pool, a different regional endpoint — survives a single-server outage and resumes on your intended operator.
3. Pool 3 (tertiary): a fully independent operator, or a self-hosted solo endpoint, so the hardware never sits fully idle.

Set it, test it, alarm on it. Then forget about it — which is exactly the point.

Frequently asked questions

How many backup pools should I configure?

At least one, ideally two. Two pools (primary plus one independent backup) covers the common case of a single operator or endpoint going down. A third slot — a different region or a self-hosted solo endpoint — is cheap insurance against a bad day at both of your first two choices. Stock Bitmain and BraiinsOS+ give you three or more slots; AxeOS gives you a primary plus one fallback.

Does my miner automatically switch back to the primary pool?

It depends on the firmware and version. AxeOS periodically retries the primary and returns to it when it recovers. Stock Bitmain builds often stay on the working backup until the miner is restarted or manually re-pointed. Don’t assume — test an outage on your exact firmware and watch what it does, then build a monitoring alert so you know which pool is active.

Is configuring a backup pool the same as load balancing?

No. Failover sends all your hashrate to the highest-priority pool that is online and only uses backups when it is down. Load balancing (quota mode, available on BraiinsOS+ across pool groups) deliberately splits hashrate across multiple pools at once. For pure redundancy you want failover, not load balancing — it is simpler to run and far easier to monitor.

Can I mix a solo pool and a shared pool in my failover list?

Yes, and it is a common pattern — but understand the payout difference. A shared pool pays smoothed, frequent rewards; a solo endpoint pays nothing until you find a full block. A long stint on a solo backup means a long stretch of zero payouts even though the hardware is busy. Also confirm the username format matches each pool (on-chain BTC address for solo, account name for many shared pools).

Why did my hashrate drop after failing over to a backup pool?

Almost always latency. A backup in a distant geographic region has a higher round-trip time, which increases stale and rejected shares and shaves effective hashrate even though the miner shows “connected.” It is fine as a temporary fallback; choose the nearest endpoint as your primary and use far regions only as deeper backups.

How do I know if my rig silently failed over?

Check which pool is active, not just that one is. Read the miner’s status page or its API (the cgminer-style pools command, or AxeOS’s JSON endpoint), enable worker-offline alerts on your primary pool, and watch the primary’s hashrate dashboard for an unexplained drop to zero while your local rig still reports full hashrate. Any of those is the signature of a live failover.

The Bitaxe $184.99 – $224.99Price range: $184.99 through $224.99 CAD

Shop The Bitaxe →