Introduction

An ASIC miner that keeps restarting may have unstable power delivery, cooling problems, a hardware fault, or a firmware or tuning issue. First confirm whether the entire device is rebooting: a protective pause, a single hashboard dropping out, or a lost pool connection can look like a restart but require different troubleshooting.

Check the miner's own status and logs before changing settings. This helps avoid unnecessary firmware reinstalls, hardware swaps, or repeated power cycling that may lose unsaved diagnostic information.

This checklist follows a deliberate order: confirm what is actually happening, read the miner's own logs, then move outward from cooling and hardware to firmware and network configuration. Reviewing evidence before changing settings preserves the timing details that make a diagnosis possible.

Step 1: Confirm What Is Actually Restarting

Before changing any setting, establish which of the following is occurring:

• Does the miner's web interface become unreachable and then come back? This may indicate a reboot, but a network interruption or web-service problem can look similar. Check whether system uptime has reset and whether the logs show a new boot sequence. Distinguish system uptime from mining-process uptime, which can reset without a control-board reboot.
• Does only one hashboard stop producing shares while the rest of the miner continues operating normally?
• Does the miner stay reachable locally but repeatedly drop and re-establish its pool connection?
• Does the miner appear to run normally in its own interface while the pool dashboard shows the worker as offline or shows a lower hashrate than expected?
• Does the event happen immediately at power-on, after several minutes of operation, or mainly during warmer periods?

This distinction matters because a local miner interface and a mining-pool dashboard measure different things, over different time windows. A worker shown as offline on the pool side is not, by itself, evidence that the ASIC rebooted; it only means the pool has not received hashrate or share data from that worker for a defined period. ViaBTC classifies a worker as Offline when it shows no hashrate and no work activity for between 20 minutes and one day, and as Inactive when that condition continues for more than one day (ViaBTC Help Center). Both labels describe pool-side reporting, not a confirmed hardware event, so they should prompt a log check rather than an immediate hardware response.

Step 2: Read the Miner's Logs Before Rebooting Again

Most ASIC firmware exposes a kernel log, system log, or event history through the miner's web interface. Before taking corrective action, record:

• The exact error text, not a paraphrase
• The timestamp of the event
• Whether the message refers to the whole miner or to a specific hashboard
• Any fan, temperature, power-supply, sensor, or pool-connection messages that appear immediately before the restart

In its S17-series troubleshooting guide, BITMAIN documents the kernel log as a record of the miner's operating stages that can be used to identify fan errors, missing chips or hashboards, temperature-sensor failures, and overtemperature protection events (BITMAIN Support). Some firmware may lose logs that have not been persistently saved when power is cycled. Log retention varies by firmware, so export the available logs before restarting to preserve the event sequence.

Step 3: Rule Out Temperature and Airflow Problems

If the log shows a temperature-sensor message, a fan error, or an overtemperature protection entry, check the following before assuming a component failure:

• Fan operation and reported RPM on each fan
• Fan connectors and cables for looseness or damage
• Blocked intake or exhaust paths, dust buildup on heatsinks or filters, or recirculating hot exhaust air
• For hydro or immersion-cooled units, coolant flow, inlet temperature, pump status, and any cooling-system alarms, following the manufacturer's documentation for that equipment
• Whether the affected board runs noticeably hotter than the other boards in the same chassis, rather than relying on a single general temperature figure

Firmware will typically pause or stop hashing when it detects a dangerous temperature or a failed fan, independent of any other fault. Braiins OS, for example, documents a stopped state triggered by dangerous temperature, a broken fan, or another overheating condition (Braiins Academy). Acceptable temperature and fan-speed ranges vary by miner model, cooling method, and firmware, so compare the reading against that model's documentation rather than a fixed number.

Step 4: Inspect Fans, Cables, and Hashboard Status

When a single hashboard repeatedly drops out while the control board and remaining boards stay online, the investigation should focus on that board rather than the whole unit. Relevant log entries and physical checks include:

• Missing hashboard or missing-chip messages
• Repeated temperature-sensor read failures on one board
• EEPROM or board-identification errors
• Loose, damaged, or improperly seated data and power cables between the control board and the affected hashboard
• Fan errors that block startup or trigger a protective stop

BITMAIN's S17-series troubleshooting documentation links these specific messages to checks of cable seating, power supply, firmware recovery, and, where needed, hashboard repair through an authorized service process (BITMAIN Support). Use these as model-specific examples and follow the troubleshooting instructions for your own miner. A board that is recovering or has been disabled is a different event from a full-device reboot, even though an operator may describe both as "the miner restarting."

Step 5: Check Power Delivery and the Power Supply

Power interruption or unstable power delivery is an important possibility to investigate after confirming a whole-unit restart, particularly when multiple miners on the same circuit are affected together. Checks at this stage should stay within what an operator can safely do:

• Look for site-level power events, tripped breakers, or loose external power connections
• Inspect the PDU, outlet, and power cable for visible damage or heat marks
• Review any power-supply-related messages in the miner log

Where a miner manufacturer's documentation supports it, substituting a known-good, compatible power supply can help confirm or rule out a suspected PSU fault. For example, BITMAIN's S17-series guide recommends PSU substitution when troubleshooting missing chips or temperature-sensor read failures (BITMAIN Support). If the problem traces back to facility wiring or requires opening high-voltage equipment, that work should go through a qualified electrician or the manufacturer's authorized service process rather than being attempted by the operator.

Step 6: Review Firmware, Tuning, and Recent Changes

Restarts that begin immediately after a configuration change are often related to that change rather than to a hardware fault. Useful questions include:

• Did the restarts start after a firmware update?
• Did they start after an overclock, a custom power target, an autotuning change, or an altered fan curve?
• Does the restart occur specifically during cold boot, during ramp-up, or after the miner enters a higher-power mode?
• Is the installed firmware version supported for this exact control board, hashboard, and miner model?

A firmware update should not be assumed to be an automatic fix. Firmware vendors periodically document narrow, model-specific issues; one documented example involved a temperature-sensor error that could intermittently halt mining for a short period on specific Antminer models before being corrected in a subsequent firmware release (Braiins Academy). The practical lesson is to record the exact firmware version in use and check that version's release notes before reinstalling or changing firmware, rather than assuming the behavior applies universally. If reverting is warranted, use the manufacturer's official firmware and recovery procedure, and preserve the existing logs beforehand.

Step 7: Separate Network and Pool Issues from Hardware Restarts

A miner that disconnects and reconnects from the pool is not necessarily experiencing a hardware reboot. Review:

• The configured Stratum URL and port
• The worker-name format
• DNS and gateway settings on the local network
• The network cable, switch port, and any firewall or VLAN rules that could interrupt the connection
• Authorization, job-receipt, share-submission, and rejection messages in the log

For BTC mining on ViaBTC, the documented Stratum endpoints are stratum+tcp://btc.viabtc.io:3333 and stratum+tcp://btc.viabtc.io:443, with the worker name entered as userID.workerID and an optional password; the setup page also recommends configuring more than one documented endpoint so the miner can fail over if one becomes unreachable (ViaBTC Help Center). If the log shows an explicit authorization or connection error rather than a generic timeout, that specific message should be investigated immediately rather than waited out.

A rising share-rejection rate does not, by itself, confirm that the miner has rebooted. Check the specific rejection reason and the surrounding logs before choosing a troubleshooting path. Network latency and connection or configuration problems can affect submissions, but device-side conditions also matter: ViaBTC lists high miner temperatures and firmware issues among the checks for a high rejection rate (ViaBTC Help Center). Review temperatures, firmware, and the miner's operating status alongside network conditions.

Step 8: Verify Recovery With Compatible Measurements

After taking corrective action, confirm recovery using measurements that are actually comparable:

• The miner remains powered and reachable through its own interface
• All expected hashboards and chips are detected
• Fan and temperature readings are back within the normal range documented for that model and environment
• The miner is receiving jobs and submitting shares
• The same log message does not reappear at the same point in a later startup cycle

When comparing hashrate figures, allow for the fact that local and pool-side numbers are calculated differently. ViaBTC's real-time hashrate is an average over the preceding 10 minutes, and its daily hashrate is an average over the preceding 24 hours; a miner that has just recovered from a restart can therefore show a lower daily figure for some time even though it is currently hashing normally (ViaBTC Help Center). Judging recovery from a single instantaneous reading, on either side, is not a reliable basis for concluding the issue is resolved.

FAQ

My worker shows as Offline on the pool dashboard. Does that mean my ASIC rebooted?

Not necessarily. An Offline status on ViaBTC means the worker has reported no hashrate and no work activity for between 20 minutes and one day; it can result from a network interruption, a stratum configuration issue, or a pool-side reporting delay as well as from an actual device reboot. Check the miner's own interface and logs before concluding that a hardware restart occurred.

How long should I wait before troubleshooting a worker that just started?

If a newly started miner has not yet submitted data to the pool, ViaBTC suggests observing it for 10–20 minutes, depending on its hashrate (ViaBTC Help Center). This is guidance for initial data reporting, not a universal time for hashrate to stabilize or proof that the miner is operating normally. Investigate explicit connection or authorization errors immediately rather than waiting.

Is a firmware update the right first step if my miner keeps restarting?

Not automatically. Firmware changes are sometimes the correct fix for a documented, version-specific issue, but reinstalling firmware without first reading the existing logs can erase the evidence needed to diagnose the actual cause. Identify the exact error and firmware version first, then check that version's release notes for a known fix before deciding whether to update.

Can I diagnose a power-supply fault myself?

You can check external connections, the PDU or outlet, and any power-supply messages in the miner log, and where the manufacturer's documentation supports it, test with a known-good compatible power supply. Opening or repairing high-voltage power-supply hardware should go through a qualified electrician or the manufacturer's authorized service process rather than being attempted independently.

References

• ViaBTC Help Center: How to Manage Workers
• ViaBTC Help Center: BTC Mining
• ViaBTC Help Center: Why Is the Hashrate Shown in the Mining Pool Lower Than That of the Mining Machine
• BITMAIN Support: Common Problems Indicated by Miner's Kernel Log
• Braiins Academy: Miner States
• Braiins Academy: What's New
• ViaBTC Help Center: What if the Rejection Rate is High?
• ViaBTC Help Center: What Should I Do If It Shows Offline or Inactive Workers While the Miner Is Working?