Introduction

Address immediate safety hazards and shared infrastructure outages first. Then prioritize individual ASIC repairs that offer a credible return to stable service and enough recoverable operating margin to justify their cost. A quick, high-confidence repair can deserve priority, but speed or nameplate hashrate alone is not a sufficient reason to move it to the front of the queue.

Operators managing a fleet of ASIC miners inevitably accumulate a backlog of offline units. Repairing whichever machine has been down the longest, or whichever unit carries the highest nameplate hashrate, overlooks whether the fault is hardware-related, whether it shares a root cause with other offline units, and whether the repair will recover its cost within a reasonable period.

This framework is a practical decision aid for site operators and maintenance teams, not a formal audit procedure. Immediate safety hazards override the sequence below: where an electrical fault or unsafe thermal condition is apparent, make the affected equipment safe before continuing diagnosis. For the remaining units, verify status, investigate shared causes, estimate recoverable value, and prioritize repairs.

Step 1: Confirm the ASIC Is Actually Offline

Before a unit is added to a repair queue, its status should be checked on both sides of the connection. Miner-side indicators include the local hashrate display, kernel or system logs, hashboard detection, fan status, chip and board temperatures, power-supply status, and network connectivity. Pool-side indicators include worker status, the pool's reported hashrate over a comparable time window, and the rejection rate for submitted shares.

The time window matters because local and pool-side figures are rarely calculated the same way. ViaBTC's documentation explains that its real-time hashrate display is based on the previous 10 minutes, while its daily hashrate statistic reflects the preceding 24 hours; a miner's local interface may refresh every few seconds and is not guaranteed to use the same averaging method (ViaBTC Help Center). A miner that has just restarted, intermittently disconnects, or has not completed a full 24-hour cycle can therefore show a materially lower pool-side figure without any physical fault. A discrepancy between the two readings is a prompt to check averaging windows, connection stability, and firmware compatibility—not evidence of hardware failure on its own.

Rejection rate deserves similar caution. An elevated rejection rate can reflect network latency, firmware issues, an incorrect pool configuration, or a genuine hardware problem, and it should be read alongside logs and connectivity checks rather than treated as a direct measure of hardware condition.

A pool-side discrepancy without a corroborating miner-side fault remains a diagnostic task. It should not enter the hardware repair queue until the checks identify a fault that requires repair.

Step 2: Separate Shared-Cause Faults from Individual Failures

Once a unit is confirmed to be genuinely offline rather than misreported, the next question is whether the fault is isolated to that machine or shared with others nearby. A fault affecting several miners on the same rack, circuit, switch, or cooling zone should generally be investigated before isolated board-level failures are repaired.

Relevant checks at this stage include the stratum URL, worker name, and pool connection settings; the condition of network switches, routers, and cabling; power distribution and PSU inputs; inlet temperature, exhaust path, dust accumulation, and fan condition; and whether the installed firmware matches the miner model. BITMAIN's troubleshooting documentation for ANTMINER units lists network instability, control-board issues, fan faults, PSU faults, temperature protection, firmware exceptions, missing hashboards, and unstable chips among the documented causes of zero or low hashrate (BITMAIN Support). Several of these causes—overtemperature protection triggered by blocked airflow, or a failed switch or shared uplink affecting an entire row—can produce what looks like multiple unrelated board failures when the actual cause is shared infrastructure or operating conditions.

A repair that restores several miners at once, or that removes a condition likely to cause further thermal or electrical damage, generally deserves priority over repairing a single high-hashrate unit, even when that unit's individual expected revenue is higher. Addressing the shared cause first also avoids the wasted effort of repairing a board only to have it fail again once the underlying condition recurs.

Step 3: Estimate Whether an Individual Repair Is Worth Making

After safety issues and shared-cause faults have been addressed, the remaining offline units can be ranked by the economic case for repairing each one. This step requires a planning horizon—the period over which the operation expects to keep running the unit before a fleet decision, hosting change, curtailment period, or hardware replacement. The horizon is an operating assumption chosen by the operator, not an industry-standard period.

One way to organize this comparison, presented here as a practical decision aid rather than a standard mining KPI, is:

Expected repair value = p × H × m − C_repair

This estimates incremental value compared with leaving the unit offline over the same planning horizon:

• p is the estimated probability that the repair returns the unit to stable service.
• H is the productive operating hours available within the horizon if restoration succeeds, after allowing for diagnostic, repair, shipping, and reinstallation time and expected non-operating periods. Do not reduce H again for the same repair-failure risk already captured by p.
• m is the estimated incremental net operating margin per productive hour.
• C_repair is the expected all-in cost of the repair attempt, including parts, external repair charges, shipping, and labor where applicable. Include costs incurred even if the repair fails.

Use one currency throughout. For example, if m is expressed in USD per hour, H must be in hours and C_repair in USD. Under this simplified model, an unsuccessful repair produces no recovered operating margin. A positive result supports repair relative to leaving the miner offline; it does not establish that repair is better than resale or replacement.

The operating margin itself can be estimated as:

m = R_net − C_electricity − C_other incremental

Here R_net is expected mining revenue per productive hour after pool fees; C_electricity is the unit's measured or expected electricity cost per productive hour; and C_other incremental covers hosting or cooling costs per productive hour only when those costs actually change based on whether the unit is running. All three inputs must use the same currency and hourly basis. A hosting fee payable regardless of the miner's status should not be subtracted again here, and a pool fee already reflected in R_net should not be deducted a second time.

The payout method affects how R_net should be estimated. ViaBTC's documentation lists a 4% fee on the PPS block-reward component of PPS+ and a 2% fee on its PPLNS-based transaction-fee component; standalone PPLNS carries a 2% fee (ViaBTC Help Center). Apply each fee to its corresponding revenue component. If using a single effective fee rate for PPS+, weight the component rates by their expected shares of gross revenue rather than adding them together. Use an expected revenue estimate suited to the planning horizon; short-term PPLNS receipts can fluctuate and should not be treated as a guaranteed hourly revenue stream.

When technician time, rather than parts or cost, is the binding constraint, an operation may use expected repair value divided by required technician hours as a tie-breaker among jobs of similar priority. This should supplement, not replace, safety and common-cause triage. A quick repair still needs an acceptable economic case before it receives priority as an ordinary restoration job.

A Practical Priority Framework

The table below summarizes how these questions translate into a working queue. It is a starting structure, not a fixed rule; the specific thresholds for cost, downtime, or confidence depend on the ASIC model, electricity and hosting terms, repair availability, and the operation's own planning horizon.

Verification is a gate before individual hardware repairs enter this queue. Pool-side discrepancies without corroborating faults remain under diagnosis, rather than becoming a low-priority repair tier.

The ordinary repair tiers are not an absolute ranking by repair speed. A slower job with substantially greater recoverable value may deserve priority over a quick fix; use the economic estimate and the actual resource constraint to resolve that trade-off.

Repair Versus Replace: Why Fleet Generation Matters

Hardware generation matters because a more efficient replacement may offer better economics at the site's power price. Its availability does not, by itself, reduce an existing miner's operating margin. That margin changes when the older unit's revenue or operating costs change—for example, when revenue per unit of hashrate falls, power prices rise, or the unit's operating performance deteriorates.

Use the existing unit's measured performance and the site's real power cost to estimate the value of repair. Then compare repair and replacement over the same planning horizon, accounting for acquisition and installation costs, turnaround, infrastructure compatibility, and any resale value relevant to each option. A positive expected repair value compared with leaving the unit offline is a useful first check, but the best fleet decision depends on the available alternatives.

Conclusion

A maintenance queue should address immediate hazards first, verify which units need attention, investigate shared causes, and then rank individual repairs by recoverable value and the resources required. This avoids treating a measurement discrepancy as a hardware fault or repairing machines in an order that ignores shared infrastructure and realistic repair economics.

The specific numbers will vary by site, hardware generation, and payout method. The decision remains practical: prioritize credible restorations that justify their cost within the operating horizon, and compare uncertain or marginal repairs with the available alternatives.

FAQ

Is a lower pool-side hashrate always evidence of a hardware fault?

No. Pool-side figures and miner-side figures are often calculated over different time windows and refresh at different intervals, so a discrepancy alone does not confirm a physical fault. Confirm that the time windows are comparable and check rejection rate, connectivity, and logs before opening the hardware.

Should a single high-hashrate ASIC always be repaired before several lower-hashrate units?

Not necessarily. If the lower-hashrate units share a common cause, such as a failed switch or a cooling problem affecting a whole row, addressing that shared cause can restore more total hashrate and prevent further damage, which may justify handling it before an individual high-hashrate repair.

Is the expected-repair-value formula a standard mining industry metric?

No. It is a simplified decision aid for comparing repair candidates with leaving them offline over a chosen horizon, not an established mining key performance indicator. Operators should adapt its inputs to their own costs and operating assumptions, and evaluate resale or replacement separately.

Does the payout method affect how repair economics should be estimated?

Yes. Payment methods differ in fee structure, timing, and variance. Apply fees to the relevant revenue components and use an expected revenue estimate appropriate to the planning horizon, rather than assuming recent receipts represent a guaranteed hourly cash flow.

References

• ViaBTC Help Center, "Why is the Hashrate Shown in the Mining Pool Lower than that of the Mining Machine?"
• ViaBTC Help Center, "How are profits calculated?"
• BITMAIN Support, "Troubleshooting and solutions for ANTMINER failures"