An ASIC that appears offline after a network outage needs a connection check, not an immediate factory reset. Separate three questions: can you reach the device locally, can it establish the intended pool session, and is that worker submitting fresh accepted work? Treat these as separate checkpoints rather than one green or red status.
This guide covers connection recovery, not electrical repairs, firmware installation or hashrate tuning. The sequence below is an editorial incident checklist: adapt it to your network, miner firmware and pool documentation. The cover uses an approved product photograph for illustration, not a record of a field test.
1. Define the incident before changing settings
Write down when the outage started, the time zone, the last known working state and what changed. Choose one affected machine and, if available, one unaffected machine as a comparison. Record their asset identifiers privately so that screenshots and observations stay attached to the correct devices.
Ask whether the problem affects one unit, one rack or the whole site. That is a way to choose the next investigation, not proof of a cause. A rack-wide failure deserves a shared-path check before individual miners are reset. One affected machine still needs a local-path check before anyone concludes its controller is defective.
| Observation | First comparison to make | What remains unproven |
|---|---|---|
| One miner disappeared | Its recorded address and local connection versus a working neighbor | A hardware fault |
| A rack disappeared together | That rack's network path versus an unaffected rack | That every miner needs reconfiguration |
| Local pages load, pool workers do not recover | Intended pool destination and connection evidence | Successful mining just because web browsing works |
| Pool activity returns intermittently | Timed events before and after each controlled change | A permanent repair from one successful refresh |
Keep a short incident timeline. Avoid changing the router, pool address and miner firmware together: even if activity returns, that combination leaves the actual cause uncertain.
2. Establish local reachability
BITMAIN's network guidance identifies DHCP availability and address-pool capacity as checks when miners do not obtain addresses. It also distinguishes an assigned IP from successful pool access. These are useful starting points, not a universal diagnosis for every model or network. BITMAIN network troubleshooting.
For the incident worksheet, mark the device's recorded address as either confirmed, changed or still unknown. Ask the network administrator to reconcile it with the current lease and asset record. A saved browser bookmark is only a record of an earlier address; do not treat a blank page at that bookmark as a complete diagnosis.
Compare the local observations before making a change. Keep network-policy decisions with the person responsible for the site. This checklist does not call for exposing miner administration to the public internet, opening inbound router ports or removing site-wide access controls. Preserve the current configuration before any approved adjustment.
3. Check the intended pool configuration
Read the current connection instructions for the exact pool and algorithm being used. Do not copy a remembered hostname or port from a different pool, coin or firmware guide.
Braiins Pool's connection FAQ specifically calls out username spelling, stray whitespace, the correct pool URL and relevant port restrictions. Its example connection tests address server reachability; they are not evidence of paid mining output. Those instructions apply to Braiins Pool, not every mining service. Braiins connection FAQ.
Make a private comparison between the configured destination and the pool's current instructions. Record whether they match without putting account credentials into a public troubleshooting post. If a network administrator tests the route from a laptop, note that device and network location too. A test performed elsewhere should not be silently recorded as a test from the miner itself.
For devices already running Braiins OS, its troubleshooting page identifies DNS problems as one possible reason pool URLs appear dead and notes that ports vary by pool. Use the documentation for the installed firmware; this is not a reason to install a different firmware during an unresolved outage. Braiins OS troubleshooting.
4. Make one controlled change at a time
Choose the smallest useful comparison. Record the proposed change, the person responsible, the original value and how it will be restored if it does not help. Decide what observation would count as improvement before starting.
For example, an operator might investigate whether affected devices share a network path. That is a proposed diagnostic comparison, not a report that a particular switch or provider has failed. Keep unaffected production equipment out of an experiment unless the site operator has deliberately included it.
After each change, write down the result and timestamp. If the symptom remains, avoid stacking more speculative settings on top of the first change. Return to the incident record and decide whether to restore the original configuration or escalate with the evidence already collected.
A firmware change belongs to a separate, model-specific procedure. Use our Antminer firmware download checklist if there is independent evidence that firmware work is needed; do not use an outage alone as that evidence.
5. Verify recovery at the worker level
An offline label needs interpretation. Braiins explains that its worker monitoring uses hashrate observations rather than directly monitoring the device's network connection, and that several devices sharing one worker contribute to combined statistics. Check the monitoring system you actually use before interpreting its label. Braiins monitoring documentation.
For your own acceptance record, collect fresh evidence from both the miner and the intended pool account. Identify the worker, observation time and whether new accepted-work activity continues. A screenshot from before the incident is not a recovery check. If workers are aggregated, say so instead of claiming a particular unit recovered based only on a group total.
Keep the observation window explicit. There is no single waiting period in this guide that proves every device and pool have recovered. For comparing the actual rate figures, use miner hashrate versus pool hashrate; that is a different question from establishing the connection.
6. Close or escalate with a usable record
| Record | What to include |
|---|---|
| Incident boundary | Start time, time zone and affected asset group |
| Local access | Confirmed address state and where the check was performed |
| Pool path | Pool name, intended endpoint and result of the relevant check |
| Change history | One change per entry, original setting, result and rollback decision |
| Recovery evidence | Worker identity, fresh activity and observation period |
| Remaining gap | The specific checkpoint still unresolved and its next owner |
Keep passwords and sensitive network details in the appropriate private support channel. Our Antminer log export and redaction checklist covers the separate task of preparing a diagnostic attachment.
Need help organizing a miner or hosting inquiry? Contact LeedMiner with the model, firmware version and a concise incident summary. Do not send wallet secrets or account passwords. A clear record helps route the question; it is not a promise that a network fault can be resolved remotely.
