Diagnosing Miner Downtime And Low Hashrate

Miner downtime and low hashrate are expensive because they hide in plain sight. A machine can be powered on, fans spinning, and still fail to produce the accepted work you are paying electricity for.

Good troubleshooting separates the miner into layers. Check power, cooling, network, pool, firmware, and hardware one at a time. Low hashrate is a symptom, not a diagnosis, even though the underlying mining process is built around a very specific proof-of-work target.

Compare Local And Poolside Hashrate

Local hash rate is what the machine believes it is producing. Poolside hashrate is estimated from accepted shares over time. Poolside numbers move around, especially over short windows, so avoid making decisions from a five-minute average. A one-hour view is better. A full-day view is better if the miner is stable enough to run that long.

If local hashrate and poolside hashrate are both low, look first at the miner itself: heat, power, missing boards, fan errors, firmware settings, or unstable tuning. If local hashrate looks normal but poolside credit is low, look at rejected shares, stale shares, pool region, worker configuration, and network reliability.

This split prevents wasted work. A missing board and a bad Ethernet cable can both reduce income, but they are not the same problem.

Check Shares Before Guessing

A share is proof that your miner submitted useful work to a mining pool. Accepted shares are credited. Rejected shares are not.

Some rejected shares are normal. A consistently high rejected-share rate is a warning. Stale shares often point to latency, packet loss, pool distance, overloaded networking gear, or a temporary pool issue. Invalid shares often point to unstable tuning, firmware problems, failing chips, or pool-side share validation problems like the ones described in the Bitcoin Wiki’s pooled mining notes.

Look at the type of rejection, not only the percentage. If stale shares rise after moving the miner to a Wi-Fi bridge, powerline adapter, or distant pool endpoint, suspect the network path. If invalid shares rise after changing frequency, voltage, or efficiency mode, suspect the tuning profile. If several miners show the same problem at once, suspect shared infrastructure before blaming one machine.

Confirm Pool And Network Stability

Most ASIC miners talk to pools through the Stratum protocol. Mining does not need much bandwidth, but it does need a steady connection. Small interruptions can reduce credited work even when the machine appears healthy, and Braiins’ Stratum V2 overview is useful background on why pool communication matters.

Use wired Ethernet when possible. Replace the cable with a known-good one. Try another switch port. Confirm the miner has a stable IP address. Check that the pool URL, worker name, and password are correct. If the pool offers regional endpoints, choose the closest reliable one. Configure backup pool URLs so the miner does not sit idle when one endpoint fails.

If one miner disconnects while others on the same network stay connected, focus on that miner, cable, port, or firmware. If every miner disconnects together, focus on the router, switch, modem, ISP, DNS, or pool availability.

Look For Heat And Airflow Problems

Heat is one of the most common causes of downtime and low output. ASIC miners turn nearly all input power into heat. If that heat is not removed, the miner may throttle, restart, submit bad work, or shut down.

Do not judge cooling by whether the room feels comfortable. Judge it by intake temperature, exhaust removal, board temperatures, fan speeds, and stability under load. Hot exhaust looping back into the intake can make a miner unstable even in a large room.

Check the cooling system in plain physical terms. Are filters clogged? Are fans working? Is dust blocking heatsinks? Is exhaust being pushed away from the intake side? Does the problem get worse in the afternoon or when the room is closed?

For home setups, the guide on heat, noise, and cooling for home miners covers the practical side of moving hot air out of a room.

Inspect Boards, Fans, And Logs

Most ASIC dashboards show each hash board separately. Check whether every board is detected, whether chip counts look normal, and whether one board reports much lower hashrate, higher temperature, or more hardware errors than the others.

The control board can also create confusing symptoms because it coordinates network settings, fans, hash boards, pool connections, and firmware behavior. A control-side problem can make otherwise healthy boards look unstable.

Read the logs before touching hardware. Look for board-detection errors, fan errors, voltage warnings, temperature shutdowns, pool authorization failures, and repeated boot loops. Used machines deserve longer tests because some faults appear only after several hours at full heat.

Treat Power As A Real Suspect

Unstable power can cause restarts, missing boards, fan errors, low hashrate, or random-looking crashes. The power supply has to deliver sustained load, not just survive startup.

Check connectors, cable seating, voltage, breaker behavior, and any signs of heat damage. Loose plugs, undersized cables, weak circuits, shared loads, damaged connectors, and overheating PSUs can all reduce stability.

Do not keep rebooting a miner that smells hot, trips breakers, shows burn marks, or has damaged plugs. Stop and fix the electrical issue first. Mining equipment is a continuous high-load appliance, so treat the power path as part of the mining system.

If the miner runs at a low-power profile but fails at a high-performance profile, that is useful evidence. It may mean cooling, power delivery, or board condition cannot support the higher setting.

Roll Back Recent Changes

When a problem starts after a change, respect the timeline. Mining software and firmware control pool URLs, worker names, fan behavior, frequency, voltage, power limits, and restart behavior. One wrong setting can create hours of downtime.

Return to the last known-good configuration. Change one variable at a time. Do not switch pools, update firmware, change network hardware, and apply an overclock in the same troubleshooting session. If performance improves, you need to know which change mattered.

The basics in mining software and firmware are worth reviewing if the miner dashboard is showing errors you do not recognize.

Use A Simple Troubleshooting Order

Use the same order every time:

1. Check physical condition, fans, dust, plugs, and obvious damage.
2. Confirm cooling: intake temperature, exhaust path, board temperatures, and fan speed.
3. Confirm network: Ethernet cable, switch port, IP address, pool URL, and backup pools.
4. Compare local hashrate with poolside accepted shares over a meaningful window.
5. Read logs for board, fan, voltage, temperature, pool, and firmware errors.
6. Roll back recent firmware, pool, or tuning changes.
7. Consider replacement parts only after the evidence points to hardware.

This order keeps troubleshooting practical. A miner may be down because a board failed, but it may also be down because a cable is bad, heat is recirculating, the worker name is wrong, or the pool endpoint is too far away.

Track Normal Before It Breaks

The best time to collect baseline data is when the miner is healthy. Write down normal hashrate, poolside average, rejected-share rate, fan speed, board temperature range, intake temperature, firmware version, pool URL, worker name, and power profile.

Those notes turn vague symptoms into patterns. If restarts happen at the hottest time of day, cooling is suspect. If rejected shares rise after a firmware update, configuration is suspect. If one board slowly drifts below the others, hardware is suspect.

Mining rewards steady accepted work. A miner that runs cleanly for weeks is usually more valuable than one that shows a high number for ten minutes and then crashes. Diagnose in layers, change one thing at a time, and let the evidence point to the cause before spending money on parts.