How to Test ASIC Miner Pool Failover: Backup and Recovery Checks

Test ASIC miner pool failover on one identified machine by proving that its backup accepts work, interrupting only the primary connection through a controlled, reversible test, and checking where shares arrive. Then restore the primary path and verify recovery separately. Keep local management available throughout. A saved backup address, a connected status, or a manually selected pool does not prove that automatic switching will work during an outage.

Decide which failure the test should cover

A backup pool can help when the primary destination becomes unavailable. It cannot supply a missing internet connection or keep a powerless miner running. Before touching settings, write down the failure you want to reproduce and the parts that must remain available.

Failure under test	Keep available	Evidence the test can establish
One primary pool connection becomes unavailable	Miner power, management access, internet and backup path	Whether the configured fallback takes over for that connection failure
An upstream pool behind a local proxy becomes unavailable	Miner-to-proxy connection and the proxy's backup route	Whether the proxy moves work to its intended upstream backup
A local mining proxy becomes unavailable	Miner management, internet and a separately configured device backup	Whether the miner can bypass that proxy
The site's internet connection fails	A separately arranged working internet path, if one exists	Network recovery; pool rows alone cannot provide it

This is an operator verification plan, not a universal manufacturer test procedure. Use the exact firmware and network documentation to choose a supported method. If you cannot isolate the intended failure and undo it without losing access, stop at configuration review and arrange an attended test with the person responsible for the network.

Establish the actual selection policy

Record the miner identity, firmware version, active destination, worker name and every configured backup. Save the original settings somewhere accessible without the miner. Keep power targets, cooling settings and firmware unchanged during the drill so a separate change cannot explain the result.

Bitmain's explanation of the three pool rows describes a primary connection followed by spare destinations when earlier connections fail. That describes the covered interface; confirm the behavior of the firmware actually installed. Pool groups that deliberately divide work are a different arrangement from an ordered backup list. Record any allocation policy before deciding that work at a second destination is unexpected.

Also check who receives the work. A second provider may need its own account, worker format and payout configuration. Match those fields against that provider's current instructions. Do not copy a website login password into a mining password field unless the pool explicitly requires that credential.

Let the miner finish its normal startup or tuning process. Capture the working primary's connection state, accepted and rejected counters, pool-side worker identity and observation time. This is the baseline to which recovery will be compared.

Qualify the backup before testing automatic switching

Use a supported manual selection or a temporary priority change on the test miner to verify the backup independently. Preserve the original order first. Confirm that the intended backup authorizes the correct account and accepts new work; then restore the original primary order and verify the baseline again.

Label this result precisely: the backup works when selected. It does not establish whether the miner will detect a failed primary or switch by itself. Keeping those two questions separate makes a failed drill easier to diagnose. If the backup cannot accept work on its own, fix its endpoint, protocol, identity or account configuration before introducing an outage.

Look at new activity rather than a lifetime total. Bitmain's pool-information reference exposes connection status, priority and accepted/rejected counters as separate fields. Where your device offers equivalent information, record before-and-after values for each destination. A historical accepted count can remain visible after a connection stops doing useful work.

Run one controlled primary-path interruption

Choose an attended maintenance window and define a rollback condition before starting. The condition can be an agreed maximum disruption or loss of reliable observation; it is your operational limit, not a claimed timeout for all ASICs. Keep a person or management route available to undo the test.

1. Confirm that the original primary is active and the proven backup remains configured. Record the start time and counter baseline.
2. Use a documented test facility, or have the network operator temporarily make only this test miner's primary destination unreachable. Keep its backup, DNS and management path available. Record exactly what was blocked and how it will be restored.
3. Observe the primary failure indication, the destination the miner selects, and new accepted activity at that destination. Preserve logs and timestamps instead of repeatedly refreshing one hashrate card.
4. Check the intended account at the backup pool. Confirm that the correct worker or documented proxy identity receives the work.
5. Restore the original path at the planned limit or sooner if access, attribution or miner operation becomes uncertain. Save the evidence before restarting anything.

A temporary network rule requires knowledge of the actual destination and routing behavior. A hostname may resolve to multiple addresses, and two pool entries may share infrastructure. Blocking a shared address or port can accidentally remove both paths. If the operator cannot prove the rule's scope, do not treat that drill as a valid primary-only test.

Changing a primary URL to a deliberately unusable value tests response to that changed configuration. It may also restart the mining process, so it is not equivalent to an established connection failing. Document the limitation if that is the only supported test available. Never use an unrelated public endpoint as a test destination.

Record recovery as carefully as the outage

Restoring network access begins the recovery check. Watch whether the installed firmware returns to the preferred primary automatically, stays on the working backup, or requires the documented operator action. This return is often called failback. Do not assume that different firmware versions use the same retry or selection policy.

Checkpoint	Record	Accept the result when
Working baseline	Physical miner, primary identity, time and counters	The expected primary receives new accepted work
Failure introduced	Exact scope, timestamp and rollback action	Only the intended primary path was interrupted
Backup active	Selected destination, first observed acceptance and pool identity	New work reaches the authorized backup account
Primary restored	Restoration time and subsequent selection behavior	Behavior matches the documented or agreed recovery policy
Drill closed	Final configuration, active worker and removed test changes	Original intended settings are restored and useful work continues

Keep connection timing and accepted-share timing separate. A connection can recover before the next qualifying share arrives. Record the first observed event without presenting it as the exact internal switch time. If telemetry cannot expose an event, mark it unknown instead of estimating it from a chart.

Pool dashboards can use different averaging windows and update schedules. When the backup or restored primary looks low, use the worker and measurement-window checklist to align identity, timestamps and credited work. If share difficulty changes, raw share counts are not an equal-work comparison. Use difficulty-weighted work where available, or retain separate intervals. A slow hashrate display alone does not invalidate a confirmed connection and accepted-work transition.

Hold the result if attribution is uncertain, only old counters are visible, or several paths failed at once. Roll back if the test creates an unplanned interruption or you lose reliable control. A useful record states both what passed and which failure modes remain untested.

A proxy creates a second place to verify

When miners connect through a local proxy, a healthy miner-to-proxy connection does not identify the upstream pool receiving the work. Inspect the proxy's active upstream and its accepted-work evidence as well as the miner's status.

The Braiins Farm Proxy configuration guide describes backup routing levels and recommends a backup pool connection on the miner for proxy failure. Those are separate protections. An upstream outage drill can verify the proxy's routing while leaving the proxy itself healthy. Testing a proxy failure requires a separate, isolated scope and a working device-side fallback. Do not stop a shared proxy just to test one machine when other miners depend on it.

How much independence is worth maintaining?

Different endpoint names do not reveal every shared dependency. Another port may help with a port-specific restriction but still depend on the same operator and internet path. A second provider can add operational separation while also adding another account, payout policy and balance to maintain. The right arrangement depends on which failures matter to your operation and whether someone will keep those backup details current.

Use the completed worksheet as the acceptance record for that configuration. Revisit it when firmware, pool credentials, network rules, proxies or provider endpoints change. The unresolved decision is how often to rehearse an unchanged setup: frequent drills consume attention and interrupt work, while an untested backup can become stale. Choose an interval you can sustain, and make each future drill answer a specific uncertainty rather than repeating a ritual.

Frequently asked questions

Can I test pool failover by unplugging Ethernet?

Unplugging the miner's only Ethernet cable usually removes access to both the primary and backup pools, as well as local management through that cable. It therefore tests link loss, not an isolated primary-pool failure. For a pool drill, keep the backup and management paths working while an authorized operator interrupts only the intended primary path. Test internet or cable recovery separately and describe that result according to its actual scope.

Does manually switching to the backup prove failover works?

Manual selection proves that the backup can work under the conditions you tested, provided new shares reach the intended account. It does not prove automatic failure detection, priority selection or recovery. Treat it as a prerequisite. Restore the original configuration, confirm the primary baseline, and then use a supported, reversible interruption to observe automatic behavior. If no controlled interruption is possible, record backup connectivity as verified and automatic failover as unverified.

How long should an ASIC take to switch pools?

There is no single timeout you can apply across firmware, protocols, proxies and failure types. Use the installed product's documentation and record what you actually observe. Keep the connection event, first accepted share and pool-dashboard update separate because they describe different moments. Set a maximum disruption you are willing to allow before the drill begins. Reaching that limit is a reason to restore service and investigate, not proof of a universal firmware defect.

Why does hashrate look low after the backup starts working?

The backup pool may not yet have a full reporting window for that worker, and qualifying shares do not arrive at perfectly regular intervals. Confirm the active destination, correct account and new accepted work before judging a short chart. Compare matching observation windows and keep share-difficulty changes visible. If attribution remains unclear or rejected work rises, retain the logs and investigate those facts instead of repeatedly restarting the miner to refresh its displayed rate.

Can the primary and backup belong to the same pool?

They can, when the operator provides supported alternatives, but the protection depends on what those alternatives share. A different port or endpoint can remain dependent on the same provider or site internet connection. Write down which failure the arrangement is intended to cover. A different provider adds another operational dependency to maintain as well as possible separation. Verify its account, worker and payout details before relying on it during an outage.

What if the miner stays on the backup after the primary recovers?

Check the installed firmware's priority and return policy before assuming it malfunctioned. Preserve the working backup while checking whether the primary is reachable and authorized again. Record any documented operator action needed to restore the preferred destination, then confirm new accepted work there. If the behavior conflicts with the documentation, provide support with the original settings, firmware version, failure and restoration times, active destinations and logs rather than only a hashrate screenshot.