Solutions for Zero Hashrate Issues in Mining Operations

A zero hashrate means the miner is powered but not producing accepted work — the fix is to walk the signal chain in order: pool credentials, network path, firmware, then the hashboards and PSU. Chasing the boards first is the classic mistake; most zero-hash calls are resolved upstream, at the pool or network, before a screwdriver comes out. This guide is the general decision tree. If your miner hashes normally cold and then drops to zero once it warms up, that is a distinct thermal fault — see the reboot-recovery guide linked at the end.

Read the dashboard before you touch anything

“Zero hashrate” is not one symptom. Pull the miner’s status page and note which of these you have — each points at a different layer:

• Real-time (RT) hashrate 0, average (Avg) still climbing or non-zero: the unit was hashing and just lost its connection or a chain dropped. Look upstream first.
• Both RT and Avg at 0: the miner never got work accepted this session — pool/config or a boot-stage board fault.
• “No data” / blank status: the control board isn’t reporting. Confirm it actually booted and is reachable before assuming a hashing fault.
• ASIC status grid full of x (or a chain reading like 0/15): chips on a chain aren’t responding to the enumeration scan. That’s a hardware/power/data-cable path, covered below.

Step 1 — Pool and worker configuration

The cheapest failure to rule out. A miner that cannot submit shares does not keep burning full power — modern firmware idles or throttles hashing when it has nowhere to send work, so a config error often reads as zero or near-zero hashrate rather than a hot, screaming box.

1. Verify the stratum URL, port, and worker name exactly, character for character. A trailing space, wrong port, or a worker the pool doesn’t recognize will show accepted shares at zero.
2. Check the pool dashboard: is the worker online but at 0, or absent entirely? Absent means the miner never reached the pool (go to Step 2). Online-at-0 usually means auth or a stale worker record.
3. Confirm all three pool slots — a dead primary with no working backup leaves the miner with nowhere to hash.

Step 2 — Network path

If the pool never sees the worker, the packets aren’t getting out.

1. Confirm the miner has an IP and is reachable on your LAN. If ARP can’t resolve the miner’s IP to its MAC, or a ping fails, the control board is the problem, not the hashboards.
2. Check for a duplicate IP — two devices fighting over one address will make a miner appear and vanish.
3. Test the physical layer: reseat the Ethernet cable at both ends, try a known-good cable and a different switch port.
4. Confirm DNS/gateway if the pool is addressed by hostname — a miner that pings by IP but can’t resolve the pool domain reads as pool-down.

Step 3 — Firmware and configuration state

1. Reboot once, cleanly. A single power-cycle clears transient enumeration failures. If it comes back and stays up, log it and watch — a unit that only recovers on reboot and then fades is the thermal case, not this one.
2. Check the error log for a fan fault. A message like Fatal Error: some Fan lost or Fan speed low! means firmware halted hashing to protect the ASICs — it reads as zero hashrate even though the boards are fine. Confirm every fan spins up at boot; reseat or replace any fan that’s stalled, unplugged, or reporting low RPM, then restart.
3. Check firmware version. Out-of-date or mismatched firmware can fail to enumerate a chain. Reflash the correct build for the exact model — never cross-flash firmware from a different board revision.
4. Confirm the pool protocol matches. Native Stratum V2 is only supported by BraiinsOS+ and AxeOS v2.14.0+; stock and other stock-based firmware speak Stratum V1. Pointing V1 firmware at a V2-only endpoint (or vice-versa) yields a connected-but-zero worker.

Step 4 — Hashboard data and power path

Only now, after the network and config are clean, do you open the case. A chain that shows all x failed its chip scan — the control board couldn’t talk to the ASICs on that board.

1. Reseat the data ribbon cables. Each hashboard talks to the control board over an 18-pin ribbon (3.3V power, ground, RST, TX, RX, and I2C clock/data) on Chain0/Chain1/Chain2. A lifted or dusty connector is the single most common cause of one dead chain. Power down fully, unseat, inspect the pins, reseat firmly.
2. Swap-test the cable and the port. Move a suspect board’s ribbon to a known-good control-board connector; if the fault follows the cable, replace the cable, not the board.
3. Confirm the power feed to the board. On the S9 each hashboard has its own power connectors; on S17/S19/S21-class units the boards feed from a bolted copper bus-bar — check that the bar bolts are torqued and not arcing/discolored. A single loose lug starves one board to zero.
4. Isolate. Run the miner on one board at a time. If two boards hash and one never enumerates, the fault is on that board. Voltage is regulated per domain — a group of chips shares one regulator, so a dead domain drops a block of chips together, not one at a time.

Step 5 — Power supply

A failing PSU can drop a whole miner or one board to zero and throw bogus temperature/status readings (all x, or fixed junk values). Test with a known-good, correctly-rated PSU for the model.

• Match the supply. APW9/APW9+/APW8-class supplies run on 110/120V at reduced output; APW12/APW17-class supplies are 200–240V input only — feeding them 120V will not start the miner.
• Bench-test caveat: if you bench a Bitmain PSU by grounding its enable pin with no I2C control, it outputs its default maximum voltage (roughly 21V on an APW9, ~15V on an APW12). A healthy supply reads high on the bench — firmware lowers it to the hashboard target at boot. A high bench reading is normal, not a fault.
• Safety: the low-voltage DC bus (8–21V) is not a shock hazard, but the mains and PFC capacitors inside the sealed PSU shell sit at ~400V+. Do not open a PSU shell; test it as a sealed unit.

Common mistakes

• Tearing into the boards before ruling out pool/network — most zeros live upstream.
• Assuming a zero-hash miner is drawing full power. It isn’t; it idles when it can’t submit work.
• Reseating ribbons with the unit powered — always kill power first.
• Blaming “the chip” for a whole-domain dropout, or replacing a board when the fault was the cable or a bus-bar lug.

When to escalate

If one chain still won’t enumerate after a clean cable/port swap and single-board isolation, the fault is on the board itself — a dead ASIC, domain regulator, or (on pre-S21 boards) a PIC. That’s bench-repair territory, not a field fix. Document which chain fails and what the ASIC status grid shows before you send it in.

Related: Localize the failing chain with the ASIC fault finder, source connectors and boards from ASIC repair parts, and if the board itself is dead, start a repair with us. If instead the miner hashes fine cold and drops to zero only once it heats up, that’s the thermal case covered in the reboot-recovery guide.