Nonce Bitcoin Mining: Why Zero Hashrate and Offline Need Separate Handling

In day-to-day Bitcoin farm ops, "a miner is not producing hashrate" is often loosely labeled as "the miner dropped" or "the miner is offline." In real fault handling, zero hashrate and offline are not the same state, and they should not share one troubleshooting flow. Zero hashrate usually means the management system can still discover the miner—the device may stay online, have an IP, and keep the control board working—while real-time hashrate has fallen to 0. Offline means the management system cannot normally fetch the miner's latest status; the issue may sit in power, network, the control board, a switch, the Agent-to-miner link, or even the whole farm infrastructure layer.

That distinction looks like status taxonomy, but it directly affects how fast a farm can respond. If every abnormal miner lands in one "fault" list, operators must check machine by machine whether it is still reachable but not mining, or already unreachable. For tens of machines the cost is limited; for thousands or tens of thousands of ASICs, wrong classification wastes a lot of time on dead-end checks. So in Nonce's farm management logic, zero-hashrate miners and offline miners need to be identified and handled separately.

What Is Zero Hashrate? What Is True Miner Offline?

The simplest way to tell them apart is to ask: can we still obtain this miner's data normally right now?

If the management system can still reach the miner and knows its IP, model, temperature, uptime, and so on, but current hashrate is already 0, that is closer to "zero hashrate." The miner is not necessarily powered off, and it has not necessarily lost network. The control board may still run normally while hash boards stop computing because of thermal protection, fan faults, PSU issues, pool connection failure, firmware problems, or hash-board failure.

BITMAIN's ANTMINER troubleshooting notes also split "cannot find IP," "cannot power on," "zero hashrate," and "low hashrate" into different fault categories. Zero hashrate may come from heat, fans, PSU, hash boards, firmware, or network issues, while "cannot find IP" should first check network and the control board.

Offline is different. The more important offline signal is not "whether hashrate is 0," but that the miner's status data can no longer update normally. The device may have lost power, a cable may be unplugged, a switch may be down, or the control board may have stopped responding so the management system cannot keep talking to the miner. In hosting scenarios, offline causes BITMAIN lists also include relocating devices, fan failure, control-board failure, hash-board failure, PSU failure, high/low temperature, PDU failure, power limits, power-facility maintenance, and network faults.

So "zero hashrate" describes the miner's compute state, while "offline" is closer to the miner's connectivity and data reachability. A miner can be online with zero hashrate; an already offline miner may even show a last recorded hashrate that is not 0, because real-time data is unavailable.

State	Can the management system get miner data?	Must it produce hashrate?	Priority check direction
Normal online	Yes	Yes	Usually no action
Zero hashrate	Usually yes	No	Temp, fans, PSU, hash boards, pool, firmware
Low hashrate	Yes	Some, but below expectation	Hash boards, temp, frequency, PSU, network
Offline	Cannot get latest status normally	Cannot confirm	Power, network, switch, control board, Agent link
Sleep or intentional stop	Yes, or state is clear	No	Confirm it is expected policy

That is also why farm management cannot rely on a single "is there hashrate" metric. Online status, hashrate status, temperature, error messages, operating mode, and last communication time need to be combined to know what actually happened.

Why Should Zero Hashrate Not Be Handled Like Offline?

The most common zero-hashrate mistake is seeing 0 hashrate and immediately treating the miner as dropped, then starting from switches, cables, or IP. If the control board is still online, that order often wastes time.

Taking the S19 series as an example, BITMAIN's listed zero-hashrate causes include thermal protection, fan failure, PSU anomalies, network or pool errors, and hash-board failure. When thermal protection trips, the miner cuts power to hash boards so hashrate goes to zero, but the control board may still be online; fan faults can likewise trigger protection and stop hash boards; if the PSU cannot feed hash boards properly, the control board may keep running while ASIC chips cannot start computing. (Source: BITMAIN S19 zero-hashrate fault notes)

That means when the miner is still reachable, troubleshooting should prioritize "why hashrate did not start," not "why the network broke."

For example, operators can first check miner temperature and fans, then error logs and whether all hash boards are recognized, then confirm pool URL, worker name, and network connectivity. If those look fine, move on to PSU or hash-board hardware faults.

Another BITMAIN zero-hashrate guide also notes that when real-time or average hashrate is 0, you can check hash boards and data cables, firmware, pool connection, network, fans, temperature, and PSU in turn. (Source: BITMAIN Hashrate Showing ZERO)

So zero hashrate is first an internal running-state problem, and only then possibly a network problem.

For large farms, it is better to use Nonce miner filters first to select devices with hashrate 0 that are still online, and handle that group on its own. That way operators do not mix truly lost devices with ones that can still be operated remotely.

Why Should Offline Miners Check Power and Communication First?

The offline troubleshooting logic is almost the opposite.

If the management system can no longer get a miner's real-time status, you may not even be able to open the miner UI to inspect temperature, fans, or hash boards. So the first step should not dig into internal hardware—it should confirm whether the device still has the basic "online conditions."

A typical path starts with power and network: is the device powered, is the PDU healthy, did a whole rack lose power; then cables, switch ports, and VLAN; if many devices on the same subnet go offline together, check network infrastructure before tearing down ASICs one by one. If power and network look fine but you still cannot get an IP or reach the control board, then inspect the control board.

For architectures that connect miners through a local management node, add one more question: is the miner offline, or did the Agent that collects data fail?

In Nonce, the Agent sits on the farm LAN, discovers and connects ASICs by scanning configured IP ranges, then syncs data to the Workspace. So one offline device may be a single-miner issue; if a whole IP range stops updating, check the Agent, VLAN routing, switches, or network config. Related connection issues can be narrowed with Nonce Agent scan troubleshooting.

That distinction between single-device faults and infrastructure faults matters a lot.

For example, if 200 miners suddenly show "offline" and they sit under the same rack or switch, rebooting ASICs one by one barely helps. The real problem may be a switch power loss, an uplink outage, or a PDU fault. Conversely, if only one device is offline while dozens next to it work normally, the fault is more likely a single PSU, cable, or control board.

How Do Correct Troubleshooting Orders Differ for Zero Hashrate vs Offline?

Once the two states are split, a farm can run two clearly different fault flows.

Stage	Zero-hashrate miner	Offline miner
Step 1	Confirm the miner is still reachable	Confirm the miner has power
Step 2	Check temperature and fans	Check PDU and power
Step 3	Check error logs	Check cables, switch, and network
Step 4	Check hash-board recognition	Check IP and control board
Step 5	Check pool connection	Check Agent-to-miner network reachability
Step 6	Try reboot	Restore communication, then judge running state
Step 7	Check PSU / hash-board hardware	Enter device-internal fault checks

One important ops principle: remote reboot only really matters after you can communicate with the miner.

When a zero-hashrate miner is still online, the platform can send a reboot task. If zero hashrate came from a transient software glitch, miner-process issue, or some recoverable state, reboot may bring hashrate back. BITMAIN also separately documents cases where "hashrate is 0, restored after reboot," which may involve thermal protection or PSU anomalies. (Source: BITMAIN zero-hashrate reboot recovery notes)

When a device is fully offline, software usually cannot keep sending ordinary reboot commands. Continuing a policy of "auto-reboot every abnormal miner" then means sending actions that unreachable devices cannot execute. Offline devices should restore power or communication first, then enter normal device-level handling.

So zero hashrate fits automated recovery better; offline fits infrastructure alerts and human localization better.

Why Do Large Farms Especially Need to Split These States?

The larger the farm, the more status classification matters. Suppose a 10,000-miner farm has 300 abnormal devices at one moment. If the system only says "300 abnormal," field staff struggle to judge workload and priority. If it further says 210 are online but zero hashrate, 70 are low hashrate, and 20 are offline, the response strategy changes completely.

The 210 zero-hashrate miners can first be checked and recovered in batch remotely; the 70 low-hashrate devices can keep running while entering second-priority checks; the 20 truly offline machines need clustering by rack, switch, PDU, IP range, or farm zone to see whether a shared fault exists.

Nonce can use multi-condition filters to combine running state, hashrate, temperature, and other conditions to locate problem miners, instead of mixing every abnormal device into one list. For devices that need remote recovery, you can also batch reboot after filtering.

This changes the basic unit of farm ops. The traditional habit is "see one broken, fix one"; scaled farms need device sets by anomaly type—for example "online and zero hashrate," "hot and low hashrate," "subnet mass offline," "same model repeatedly abnormal." Ops objects shift from single miners to groups with shared traits so efficiency stays stable as the fleet grows.

When Automating Zero Hashrate, Do Not Simply Set "0 Hashrate → Reboot"

Splitting zero hashrate from offline is only the first layer. Once automation starts, you also need to judge whether the anomaly persists, and whether the miner should not be producing hashrate in the first place.

For example, right after boot, hashrate may need time to stabilize. If the system reboots the moment it sees 0, you can get a start → rule fire → reboot → start loop. Similar issues appear during manual repair, intentional stop, or sleep mode. So a better automation rule should include both a "hashrate threshold" and a "duration."

Nonce auto-reboot can recover based on hashrate below a configured threshold. In real farms, rules should avoid treating every brief blip as a true fault—leave a reasonable observation window.

A fuller auto-recovery loop can be read as: "miner online → should be mining → hashrate below threshold → anomaly lasts past the observation window → reboot → wait for recovery → check hashrate again."

Offline devices should take another path: "device data not updating for a long time → judge blast radius → check for clustered offline → check Agent, network, or power → restore communication → re-fetch miner status → then decide whether reboot or repair is needed."

Same "No Revenue," Completely Different Fault Layers

From a revenue view, zero hashrate and offline end in a similar outcome: the miner is not submitting valid work to the pool normally, and the farm loses BTC it should have earned. From an ops view, they sit on completely different fault layers.

Zero hashrate usually means "the management path is still alive, but the mining path failed." The farm can still get device info, read logs, and run remote actions, so many issues can be localized quickly in software.

Offline means "even the management path itself may be dead." Then the real problem may not be the ASIC at all—it may be power, network, switches, routing, the Agent, or whole-rack infrastructure.

That is why a mature Bitcoin farm management system cannot simply equate "hashrate 0" with "miner offline." Only when connection status, real-time hashrate, temperature, miner mode, error messages, and data-update time are recorded separately can operators tell which layer failed.

In Nonce, you can first query zero-hashrate miners to find devices still online but not computing, then query offline miners to locate devices that already lost connectivity. For large farms, these are not just two UI filters—they are two different ops paths: zero hashrate prioritizes "why the machine is not hashing"; offline prioritizes "why the machine is not visible."

Only by splitting those problems can you move on to batch troubleshooting, auto recovery, and severity grading. When a farm grows from hundreds of ASICs to thousands or tens of thousands, what often decides ops efficiency is not how many faults you find, but whether you can send each fault into the right handling path the moment you find it.