Start by Confirming What Actually Restarted
A miner that appears to be restarting repeatedly is not always experiencing a full device reboot. Several distinct events can look similar from a distance, and conflating them leads to wasted repair effort:
- A full device reboot — the control board resets, system uptime returns to zero, and the log shows a new boot sequence.
- A hashboard or mining-process recovery event — the device stays reachable through its web interface while one board, or the mining process itself, restarts under firmware control.
- A pool-connection interruption — the miner loses its Stratum session and appears offline in the pool dashboard, with no change to local uptime.
- A reporting delay after startup — a newly started worker has not yet submitted enough share data for the pool to mark it active.
The first diagnostic step is to open the miner's own web interface (or SSH/API if available) and check system uptime directly on the device, rather than relying on a pool dashboard label. ViaBTC's support documentation notes that a worker can show as Offline or Inactive for reasons unrelated to a hardware restart, including configuration errors, network instability, or a device that is still idling after a power event and has not yet submitted data to the pool (ViaBTC Help Center). If the worker has only just started, ViaBTC's documentation suggests allowing roughly 10–20 minutes before treating the Offline label as a fault, since the exact delay depends on the miner's hashrate and share submission rate.
This distinction matters because the correct next step differs sharply depending on which event actually occurred. A reset control-board uptime points toward power, thermal, or firmware causes. A stable local uptime with an offline pool worker points toward network or pool-configuration causes instead.
Preserve the Log Before You Restart Again
Once an interruption is confirmed, resist the instinct to power-cycle the unit immediately. BITMAIN's support documentation recommends reviewing the miner's log before restarting, since the sequence of events leading up to the fault is often the most useful diagnostic evidence available, and it is lost once the device reboots again (BITMAIN Support).
Before reconnecting power, record:
- The exact error text and timestamp.
- Which hashboard, if any, was affected.
- Temperature and fan-speed readings at the time of the event.
- Any power-related messages (voltage alarms, PSU faults, power-loss notices).
A single log entry such as a high-temperature alarm, a missing-chip message, or a power-loss notice points toward a different repair path than an unexplained restart with no preceding message. Repeated manual restarts without reviewing this information can obscure the original trigger and make the fault harder to reproduce or diagnose.
Work Through Causes in a Consistent Order
Most recurring ASIC restarts trace back to a small set of fault categories. BITMAIN's troubleshooting documentation for ANTMINER devices organizes these into overtemperature protection, fan or sensor faults, power-supply issues, hashboard or control-board faults, firmware problems, and network failures (BITMAIN Support). Working through them in a consistent order avoids replacing a component before ruling out a simpler cause.
1. Overtemperature protection
Check for overtemperature messages in the log, rising inlet or outlet temperature, and signs of poor airflow such as dust buildup or exhaust air recirculating back into the intake. Manufacturer-recommended operating temperature ranges vary by model; BITMAIN's documentation for the ANTMINER 19 series cites a recommended operating environment of roughly 5–35°C, but readers should confirm the applicable range for their specific model in the manufacturer's manual rather than assume this figure applies universally (BITMAIN Support).
2. Fan or temperature-sensor faults
A fan-loss error, an unusually low RPM reading, or an unreadable temperature sensor can trigger the same protective stop or restart behavior as genuine overheating, even in a properly ventilated environment. Check the fan cable and connector first, since a loose connection is a common and easily verified cause before assuming the fan itself has failed.
3. Power supply, cable, or connector problems
Look for voltage alarms, PSU fault messages, or a restart that coincides with the miner reaching full load. Loose power leads, a worn connector, or an undersized circuit upstream of the PSU can all produce intermittent restarts that resemble a hardware fault. Electrical issues beyond the miner's own cabling should be reviewed by a qualified electrician where the circuit or facility wiring is in question.
4. Hashboard or control-board faults
A missing board, missing ASIC chips during enumeration, or abnormal nonce responses from one board point toward a board-level hardware issue rather than a software one. Repeatedly restarting a miner in this state is not a repair; it can mask a fault that worsens over time.
5. Firmware or tuning instability
If restarts began immediately after a firmware upgrade or a change to frequency, voltage, or autotuning settings, the new configuration itself may be the cause. Revert only through the manufacturer's or firmware provider's documented recovery procedure, and change one setting at a time so the source of instability can be identified.
6. Network or pool-connection problems
If local uptime never resets but the pool shows the worker as offline, check the Ethernet connection, router or switch stability, DNS and gateway settings, and the configured pool URL, port, and worker name. This is the category where a miner can appear to "restart" from the pool's perspective without any underlying hardware event.
7. Intentional or policy-driven restarts
A scheduled firmware update, a curtailment command, or a fleet-management policy can restart a miner deliberately. Review firmware and management-tool event history before assuming a hardware fault, particularly in operations using remote monitoring or automated power-curtailment systems.
Separating Firmware-Level Recovery from a Full Reboot
Modern mining firmware increasingly distinguishes between a full device reboot and a smaller, targeted recovery action. Some firmware can pause or restart a single hashboard after a high-temperature event while the rest of the miner continues reporting, rather than restarting the entire control board. Treating every such event as an unexplained full reboot can lead to unnecessary hardware replacement when the firmware's own recovery message already identifies the cause and scope of the interruption. Where available, check the firmware's reported state or reason code before escalating to a hardware investigation.
Using the Pool's Workers Page as a Diagnostic Aid
A pool dashboard cannot confirm whether a device physically rebooted, but it can help narrow down whether an interruption is connection-related. On ViaBTC's Workers page, a worker that goes offline and reconnects repeatedly, without any change in the miner's own uptime, points toward the network and pool-connection category rather than a hardware fault. ViaBTC's mining setup documentation also recommends configuring a backup connection endpoint so the miner can switch automatically if its primary connection becomes unavailable (ViaBTC Help Center). This reduces disruption from a connection-path failure specifically; it does not address PSU, thermal, fan, or hashboard faults, which require the hardware-focused checks described above.
It is also worth noting, for context, that a pool's share target is intentionally easier to meet than the Bitcoin network's block target, which is why miners can submit frequent shares as pool-side proof of work between the rare blocks that meet the full network target (Bitcoin Developer Guide). A fluctuating share-submission rate during a connection interruption reflects this pool-accounting layer and should not be read as a measurement of the miner's electrical or thermal condition.
When to Escalate Rather Than Restart Again
Stop attempting further manual restarts and move to manufacturer-approved repair channels when the log shows any of the following:
- Signs of a possible short circuit.
- Partial ASIC-chip detection that persists across multiple restarts.
- Thermal protection triggering repeatedly despite confirmed adequate airflow and ambient temperature.
- Physical damage to a board, connector, or cable.
Cold-weather deployments carry an additional caution: BITMAIN's restart guidance advises against restarting a miner in ambient temperatures below -20°C, since very low temperatures can affect component behavior during startup. This guidance is specific to the cited cold-weather scenario and should not be generalized to all ASIC models or all operating conditions.
FAQ
My miner shows Offline on the pool dashboard but its local uptime hasn't reset. What does this mean?
This points toward a network or pool-connection issue rather than a device reboot. Check the Ethernet connection, router stability, and the configured pool address and worker name before investigating hardware causes.
Is it safe to just keep restarting the miner until it stays online?
Repeated restarts without reviewing the preceding log entry can mask the underlying cause and, in cases involving partial chip detection or suspected short circuits, may increase the risk of further damage. Record the log details first, then address the specific fault category they indicate.
How long should I wait before treating a newly started worker as a problem?
ViaBTC's documentation suggests allowing roughly 10–20 minutes for a new worker to begin submitting share data, and separately recommends checking operation status and earnings after about 10–15 minutes once a miner has stabilized. These are observation windows for pool reporting, not diagnostic thresholds for hardware health.
Does a firmware update ever cause restarts by design?
Yes. Scheduled firmware updates and certain automated recovery or curtailment policies can restart a miner or a single hashboard intentionally. Reviewing firmware and management-tool event history can rule this out before assuming a hardware fault.
Can I estimate my miner's power efficiency from pool-reported hashrate data?
No. Pool-reported hashrate is a share-based estimate over the pool's own measurement window, not a direct electrical measurement, and it should not be combined with power-consumption figures to calculate hardware efficiency.