Pool Failover Configuration for Miners: Primary and Backup
An ASIC pointed at a single pool with no backup is one pool incident away from zero hashrate. The fix is so simple that there is no excuse for skipping it: modern Antminer, Whatsminer, Avalon, Fluminer, and Goldshell firmware all expose three pool slots, and any rig should have at least two of those slots populated. The actual difficulty in pool failover configuration is not typing URLs into fields — it is choosing failover targets that genuinely de-correlate the failure mode, configuring the failover triggers so a flaky network does not constantly thrash the rig between pools, and monitoring the rig well enough to notice when a failover has happened so the underlying primary-pool issue can be diagnosed and fixed.
What a failover configuration actually is on a miner
Every recent firmware version from Bitmain, Whatsminer, Canaan, Fluminer, and Goldshell exposes three pool entries in the Miner Configuration tab: URL1, URL2, URL3, each with its own worker name and password. The mining client treats these as ordered priority — URL1 is primary, URL2 is the first fallback, URL3 is the second fallback. If the primary connection drops or fails health checks, the client switches to the backup; if the backup also fails, it falls to the tertiary; if all three are down, the rig hashes against the last successfully-received job until it times out, then stops.
The mechanics are identical across manufacturers because the underlying protocol is identical — stratum V1 is a client-server JSON-RPC protocol and the failover logic lives in the mining-client implementation rather than in any standardised header. Stratum V2-capable firmware exposes the same three-slot structure with the added ability to mix V1 and V2 endpoints across slots.
Choosing failover targets that actually de-correlate
The biggest mistake in failover configuration is filling all three slots with endpoints from the same pool. F2Pool primary, F2Pool backup, F2Pool tertiary is configured failover in the sense that pool-side outages of a single endpoint will trigger the switch, but it provides zero protection against a pool-wide outage — and pool-wide outages do happen. A genuine de-correlation strategy spans across pools:
- Slot 1 (primary): Operator’s preferred pool, regional endpoint nearest the rig.
- Slot 2 (backup): Same pool, different regional endpoint OR a second pool’s endpoint in the same region — depending on whether the operator prioritises pool consistency or pool-wide outage resilience.
- Slot 3 (tertiary): Different pool entirely, ideally one with a different geographic infrastructure footprint and a different parent company.
The trade-off in slot 2 is real. Same-pool fallback keeps payouts simple — every share earned still goes to one account — but offers no protection against pool-side incidents that affect all endpoints at once. Cross-pool fallback adds payout-accounting complexity but provides true outage resilience. Operators running mission-critical hashrate (financed hardware, fixed-bill hosting customers) typically pay the accounting complexity for the resilience.
Failover triggers and the thrashing problem
What actually triggers a failover? The mining client’s health check is the answer, and the specifics vary by firmware. Common triggers include: TCP connection failure or timeout on the primary, no new stratum job received within a configurable window, repeated share-rejection bursts above a threshold, or explicit operator command via API. When a trigger fires, the client closes the primary connection, opens a connection to the backup, and resumes mining against backup-issued jobs.
The thrashing problem appears when a marginally-bad primary triggers frequent failovers but is not actually broken. Imagine a primary endpoint with intermittent latency spikes that occasionally exceed the timeout threshold; the rig switches to backup, the latency improves, the client switches back, the next spike triggers another switch. Each switch costs a few seconds of mining and risks share-fork wastage during the transition. The fix is either to raise the timeout threshold (firmware-specific setting) or to swap the primary for a better-quality endpoint. Configure once, monitor, tune if needed.
Share-fork avoidance during failover
When a rig switches from primary to backup, there is a brief window where it has accepted a job from the primary, computed shares against it, and now needs to either submit those shares to the (now-closed) primary or discard them. The behaviour is firmware-specific; some clients buffer in-flight shares and attempt re-submission after reconnect, others discard them outright. The lost shares are negligible at single-failover scale but add up at fleets that thrash.
The other share-fork failure mode is misalignment between primary and backup pool ledgers. If the primary and backup are different pools, shares submitted to the primary count toward primary-pool earnings; shares submitted to the backup count toward backup-pool earnings. There is no share-fork in the protocol sense — each pool sees a clean stream of shares from its perspective — but the operator’s accounting must reconcile earnings across both pool-side ledgers. The dedicated stale-share explainer covers the related mechanism of stale shares post-block-find.
Worker-naming conventions across failover targets
The worker-name string in slot 1 typically takes the form account.worker; slots 2 and 3 take account.worker under their respective accounts. If the operator uses different pools across slots, each pool needs its own account configured and the worker name encodes the respective account prefix per slot. Same-pool failover uses the same account across slots and only varies the URL.
For per-pool worker-name conventions on specific pools, the relevant individual pool guides (F2Pool, AntPool, Foundry, ViaBTC, Luxor, Braiins) cover the account-and-sub-account models each pool uses. The general principle is consistent: a worker label that encodes physical location (rack, unit) lets monitoring systems map a “worker offline” alert from any pool’s dashboard directly to a maintenance ticket.
Monitoring the rig across pool boundaries
The catch with cross-pool failover is that no single pool’s dashboard knows about the other pool’s connection. If the operator only monitors the primary pool’s dashboard, a failover to a different pool looks like the rig has gone offline — the primary pool sees the worker drop and reports it as offline; the backup pool sees a new connection appear and reports it as online; neither knows about the other.
The solution is rig-level monitoring rather than pool-level monitoring. The rig itself knows which pool it is currently connected to and reports that in its status API. Open-source tools like Awesome Miner, Foreman, BraiinsOS’s built-in monitor, and various custom Grafana setups consume the rig’s API and surface the current pool connection in one place. The ASIC mining mechanism explainer covers what the underlying stratum status reveals; a rig-level monitor reads this same status across all rigs.
How failover interacts with FPPS and PPLNS payouts
Failover behaviour intersects payout scheme in a way that catches first-time operators off guard. Under FPPS, every accepted share earns regardless of pool block-find timing — failing over from FPPS pool A to FPPS pool B mid-day means earnings are split cleanly across the two pools’ ledgers, each settling at their respective threshold. Under PPLNS, failing over mid-window can mean the operator loses contribution credit on the primary pool’s current window if they do not return to it before the window closes; the share contribution accumulated before failover may or may not count toward a block found after the operator left.
The decision-guide on FPPS-vs-PPLNS covers the broader payout-mechanics trade-off; for failover specifically, PPLNS adds an extra reason to keep cross-pool failover infrequent (use it for real outages, not flaky-latency thrashing). For broader Bitcoin context including how the overall mining stack fits together, the Bitcoin mining hub on Coin Web Mining consolidates the supporting explainers.
A sensible failover deployment, end-to-end
A reasonable default for a single rig or small fleet:
- Primary: preferred pool, closest regional endpoint, account.workerid_specific.
- Backup: same pool, adjacent regional endpoint, same account.workerid_specific.
- Tertiary: different pool, account configured at that pool with payout address, distinct workerid_specific to keep dashboards clean.
- Rig-level monitoring exposing current pool connection per rig.
- Alert on any rig that has been on tertiary for more than 30 minutes — signals a primary-pool issue worth investigating.
The configuration is one evening’s work. The payoff is paid every time a single pool has an incident and the rig stays productive instead of dropping to zero. Hashrate Index periodically publishes post-mortems on pool incidents — the historical record is enough to justify the configuration.
Step-by-step: configuring three slots on the miner dashboard
The mechanical walkthrough is short and nearly identical across Bitmain, Whatsminer, Canaan, Fluminer, and Goldshell firmware. Open the rig’s web interface, log in, and rotate the default credentials if that has not already been done. Navigate to the Miner Configuration or Pool tab, which presents three rows, each with a URL field, a worker field, and a password field. The rows are ordered: the top row is primary, the second is the first fallback, the third is the second fallback.
Fill the URL field of slot 1 with the primary pool’s regional stratum endpoint, sourced from that pool’s current documentation rather than a forum post. Set the worker field to the pool’s expected account.worker format — and if slots 2 and 3 point at different pools, each needs its own account string for its own pool, configured under that pool’s payout address. The password field is cosmetic at most pools; a single character satisfies firmware that requires a non-empty value. Save the configuration. Most firmware applies the change live, but a power cycle removes any ambiguity about which config is active. Within five to fifteen minutes, confirm the rig is submitting accepted shares against slot 1, then confirm the failover actually works by briefly making slot 1 unreachable (a deliberate wrong port on a test rig, for instance) and watching the rig drop to slot 2.
Testing failover before you depend on it
A failover configuration that has never been exercised is a hypothesis, not a safeguard. Operators who depend on uptime should validate the failover path on a test rig before assuming it works fleet-wide. The simplest test temporarily points slot 1 at a deliberately unreachable endpoint — a wrong port, or a hostname that does not resolve — and observes whether the rig transitions to slot 2 within the firmware’s trigger window and resumes submitting accepted shares there. The rig’s status page should show the active connection move from slot 1 to slot 2, and the slot-2 pool’s dashboard should show the worker appear.
This test surfaces two common surprises. The first is a failover window longer than expected — some firmware waits a full timeout interval before switching, during which the rig is producing nothing. The second is a slot-2 account that was never actually configured at the backup pool, so the failover connects but every share is rejected for an unknown worker. Both are cheap to find in a controlled test and expensive to discover during a real primary-pool outage at 3 a.m. Restore slot 1 to its correct endpoint once the test confirms the path.
Keep the management plane off the public internet
Failover protects against pool outages; it does nothing against a compromised rig. Because every stratum connection across all three slots is outbound, no inbound port needs to be open for mining or for failover to function. Exposing a rig’s management web UI or SSH to the public internet adds attack surface with no operational benefit — and a particularly nasty failure mode is an attacker rewriting the very pool slots the operator configured for resilience, repointing all three to an attacker-controlled account.
The defensible pattern keeps miner management interfaces on a non-internet-routable LAN, with remote access gated behind a VPN and default credentials rotated on first boot. This sits alongside failover rather than replacing it: failover keeps the rig productive through pool incidents, network isolation keeps the rig’s configuration under the operator’s control. An operator who builds a careful three-slot failover scheme but leaves the management interface internet-facing has protected against the less likely failure and left the more damaging one open.
References
- Braiins documentation on stratum protocol behaviour — Braiins
- Bitmain Antminer firmware configuration documentation — Bitmain
- Hashrate Index pool analytics and incident reporting — Hashrate Index
- Mempool.space block explorer — Mempool.space