When a mining ASIC goes offline, the financial impact is often reduced to a single number: "how much did this cost me?" In practice, an outage produces several distinct costs that behave differently and should not be collapsed into one figure. A defensible estimate separates the repair invoice, the mining income the machine would likely have earned, the hosting charges that continue regardless of the fault, and any electricity or usage-based charges that are avoided while the unit is offline. Treating these as one lump sum can lead an operator to either overstate the loss (by treating fixed hosting charges as fault-induced costs) or understate it (by ignoring lost mining income entirely). This article outlines a four-part framework for building a realistic cost estimate after a mining fault.
Why a single downtime figure can mislead
The core distinction is between costs that are avoided when a machine stops running, costs that continue unchanged regardless of the fault, and costs that arise specifically because the fault occurred. Mining income obviously falls to zero for the affected hashrate during an outage. Electricity billed on metered consumption typically falls as well, since an offline ASIC draws little or no power. However, many hosting agreements include a reserved-capacity charge, a rack or management fee, or a minimum monthly commitment that continues irrespective of uptime. Those continuing fixed charges matter for outage-period cash flow, but if they would have been paid even without the fault, they are not incremental downtime losses. Whether a specific charge continues during downtime depends entirely on the billing structure written into the hosting contract — not on any general industry rule. The estimate below is built around that distinction.
Step 1: Estimate the repair cost
Repair cost should be built up from its components rather than assumed to equal the advertised part price:
Repair cost
= diagnostic fee
+ replacement parts
+ repair labor
+ shipping and insurance
+ customs or taxes, where applicable
+ on-site travel and accommodation, where applicable
+ any downtime-handling charge specified in the service agreement
Warranty coverage does not automatically eliminate every line item above. A warranty may cover parts and labor for the repair itself while leaving outbound freight, packaging, or on-site logistics to the customer. Bitmain's published after-sales terms illustrate this distinction: standard warranty on new Antminer units and new APW power supplies generally runs for 365 days, subject to the applicable sales terms, while paid out-of-warranty repairs carry a 15-day warranty under Bitmain's published repair terms. For certain on-site service arrangements involving out-of-warranty machines where no authorized repair center is available locally, the customer may bear travel and accommodation costs, and Bitmain specifies a minimum US$5,000 deposit. Its terms also describe a US$200-per-person, per-day charge in cases where technicians are unable to work for reasons not attributable to Bitmain and the applicable conditions are met (Bitmain, Product Warranty; Bitmain, On-Site Repair Service). These figures are specific to one manufacturer's terms and should be treated as an illustration of the categories to check — diagnostic fees, deposits, travel, and idle-technician charges — rather than as a benchmark repair price for any given fault.
Step 2: Estimate mining income not earned
A practical way to estimate lost mining income is to anchor the calculation to a comparable historical payout period rather than an instantaneous hashrate reading, since short-term readings can be volatile and are sensitive to the measurement window used.
Estimated BTC not earned
= normal BTC payout for a comparable period
× affected share of normal hashrate
× downtime as a share of that period
For example, if a fleet normally earns 0.50 BTC per day under typical operating conditions, and a fault takes 20% of the fleet's hashrate offline for 12 hours:
Estimated BTC not earned
= 0.50 BTC/day × 20% × 0.5 day
= 0.05 BTC
This figure represents mining income the operator likely did not earn — it is not a repair expense and should not be merged with the repair invoice. For longer outages, the baseline should continue to reflect comparable operating and network conditions. Bitcoin difficulty is retargeted every 2,016 blocks, a process designed to correspond to roughly two weeks, and network-wide hashrate can also shift meaningfully during a repair window. If an outage crosses a difficulty retarget or lasts long enough for network conditions to change materially, the expected payout baseline should be refreshed for the affected period.
When comparing hashrate figures to build this estimate, keep the measurement source consistent. A local ASIC display and a pool's estimated hashrate are not interchangeable: ViaBTC's real-time pool hashrate is calculated from valid shares submitted over the preceding 10 minutes, while a miner's local display may refresh on a much shorter interval. Mixing an instantaneous local reading with a daily pool-reported figure can distort the downtime estimate in either direction.
Step 3: Determine which hosting charges continue
This is the step most often handled incorrectly. Whether a hosting charge continues during an outage depends on the billing basis defined in the contract, which typically falls into one of the following categories:
- Actual energy consumed (metered kWh)
- Actual operating hours (uptime-based billing)
- Reserved power capacity (kW or MW), billed whether or not it is used
- A fixed monthly fee or minimum commitment
- A hybrid of a fixed component plus a variable, usage-based component
Bitmain's Host Antminer service documents one example of an uptime-based structure, where the fee is calculated as:
Host fee = $0.10/kWh × power consumption (kW) × uptime (hours)
Under this specific structure, a fully offline machine would generate no hosting fee during the outage, since uptime hours are zero (Bitmain, Host Antminer FAQ). This is one documented example of one provider's product, not a representative market rate, and it should not be assumed to apply to a different hosting agreement. Contracts built around reserved capacity, rack space, or a monthly minimum commonly continue billing during downtime, since those charges are tied to the space and infrastructure reserved rather than to the electricity actually consumed. Those fixed charges should still be tracked in the outage-period cash-flow view, but if they would have been paid anyway, they are not incremental costs caused by the fault. Before estimating a downtime cost, the hosting agreement itself — not a general assumption — should be checked for which category applies.
Step 4: Account for charges avoided during downtime
Where billing is genuinely usage-based, an offline machine typically consumes little or no metered electricity, and that portion of the normal bill is avoided rather than lost. This avoided amount should be subtracted from the total incremental impact so it is not double-counted as a loss:
Electricity or energy-based hosting charge
= measured power draw (kW) × operating hours × contracted rate ($/kWh)
Combining the relevant components produces an incremental estimate:
Incremental fault impact
= repair cost
+ mining income not earned
+ incremental outage-related charges
− variable electricity or usage-based charges avoided
Fixed hosting charges that continue unchanged during the outage should be reported separately when reviewing cash flow. They matter because the operator still has to pay them, but they should not be added to incremental fault impact unless the fault itself triggers an additional charge.
Worked example
Assume a hosting client's fleet totals 100 PH/s and normally earns 0.048 BTC per day at that hashrate. A hashboard fault takes a 5 PH/s batch (5% of the fleet) offline for 24 hours.
Mining income not earned: 0.048 BTC/day × 5% × 1 day = 0.0024 BTC.
Repair cost, based on a vendor quote: diagnostic fee plus one replacement hashboard plus return shipping, totaling a fixed cash amount agreed with the repair provider.
Hosting charges: if the contract bills a fixed monthly rack fee regardless of uptime, that fee continues unchanged for the 24-hour period and should still appear in an outage-period cash-flow review. However, because the same fee would have been paid without the fault, it is not added as an incremental downtime cost unless the contract imposes an additional fault- or outage-specific charge.
Electricity avoided: if electricity is billed on metered kWh, the batch's normal daily energy draw for those 24 hours is avoided and should be subtracted from the incremental financial impact.
The result is a downtime figure denominated partly in BTC (mining income not earned) and partly in fiat currency (repair cost and any net incremental hosting effect), which should be reported separately rather than forced into a single blended number, since combining them requires an explicit BTC/USD conversion at a stated date.
Using pool data to build the estimate
A mining pool account provides several inputs useful for this exercise: historical BTC payout records for a comparable baseline period, worker-level hashrate and status data to confirm which machines were actually affected, and rejection-rate data to help identify whether there is a share-submission or performance problem. ViaBTC's support documentation notes that a rejection rate within 3% is generally considered its normal range; a rejection rate meaningfully above that level can indicate that further diagnosis is needed, but it does not by itself distinguish a hardware fault from network instability, elevated temperatures, firmware issues, or other causes. Pool-side rejection data should therefore be considered together with local logs, hashboard status, temperatures, firmware checks, network tests, and worker status (ViaBTC Help Center, rejection rate). This threshold is specific to ViaBTC's stated normal range and should not be applied as a universal mining-industry benchmark.
When using a pool's payout history as the revenue baseline, it also matters which payment method applies. ViaBTC's PPS+ method settles the block-reward component using PPS logic, currently listed at a 4% fee, while the transaction-fee component is distributed under PPLNS rules at a separate 2% fee. Under the standalone PPLNS method, block rewards and transaction fees are distributed together at a 2% fee (ViaBTC, Fees). If the downtime baseline comes from actual historical earnings already settled to the mining account, those pool fees have already been reflected and should not be deducted again. If the estimate is instead built from a gross or theoretical reward calculation, the applicable fee should be applied to the corresponding reward component according to the payment method used.
Checklist before approving a repair or replacement
- Miner model, serial number, firmware version, and observed fault symptoms
- Local hashrate, temperatures, and hashboard status recorded before shutdown
- Pool-side hashrate and rejection-rate data for a comparable prior period
- Confirmed start and end time of the outage, in a stated time zone
- A full repair quote itemizing labor, parts, freight, insurance, and expected turnaround
- The hosting contract's billing basis: metered kWh, uptime hours, reserved capacity, or a fixed fee
- Normal recent BTC payout over a comparable period, and the payment method used
- Electricity or usage-based charges genuinely avoided while offline
Conclusion
Estimating the cost of a mining fault accurately requires separating repair cost, mining income not earned, continuing fixed hosting charges, and avoided variable costs rather than collapsing them into one blended figure. The hosting contract's billing basis — not a general assumption about downtime — determines which charges continue when a miner is offline. Fixed charges that would have been paid regardless should be tracked for outage-period cash flow but not counted as incremental fault losses, while genuinely avoided electricity or usage-based charges should reduce the estimate. Building the analysis from documented pool data, a comparable historical payout period, and an itemized repair quote produces a more defensible result than any single downtime multiplier and keeps BTC-denominated and fiat-denominated components properly separated.
References
- Bitmain, "Product Warranty," support.bitmain.com, updated October 11, 2024.
- Bitmain, "ANTMINER After-Sale On-Site Repair Service," support.bitmain.com.
- Bitmain, "HOST ANTMINER FAQ," support.bitmain.com.
- ViaBTC, "Fees," viabtc.com/en/pricing.
- ViaBTC Help Center, "What if the Rejection Rate is High," support.viabtc.com.
How do I know whether my hosting fee stops while a miner is being repaired?
Check the billing basis in the hosting contract. If the fee is based on metered electricity consumption or actual operating hours, it typically falls or stops while the machine is offline. If the fee is based on reserved power capacity, rack space, or a fixed monthly minimum, it commonly continues regardless of uptime, since it reflects infrastructure that remains reserved for the machine. A continuing fixed fee should still be tracked in outage-period cash flow, but if it would have been paid without the fault, it is not an incremental downtime loss.
Should I use my miner's local hashrate display or the pool's reported hashrate to estimate lost income?
Use whichever figure matches the measurement window of your calculation, and avoid mixing the two. A local display often refreshes more frequently than a pool's estimate, which is calculated from shares submitted over a defined window. For a daily or multi-day revenue estimate, a pool's payout history over a comparable period is generally more stable than an instantaneous local reading.
Does a manufacturer's warranty cover the full cost of a repair?
Not necessarily. A warranty may cover the replacement part and labor for the repair itself while excluding outbound shipping, packaging, on-site travel, or charges related to technician availability. Review the specific warranty terms and any out-of-warranty service terms before assuming the repair is cost-free.
How should I estimate lost mining income for a repair that takes several days?
Anchor the estimate to a comparable historical payout period rather than a single hashrate snapshot, and refresh the baseline if network conditions change materially during a longer outage. Bitcoin difficulty is retargeted every 2,016 blocks, and network hashrate can also shift during a repair window. If the outage crosses a difficulty retarget, it is more accurate to estimate the periods before and after the retarget separately.
Is a high rejection rate itself a repair cost?
No. A high rejection rate is a diagnostic signal, not a cost in itself. It can indicate a share-submission or performance problem, but it does not by itself establish that a hardware repair is needed. Confirm the cause using pool-side data together with local logs, temperatures, firmware, network checks, and hashboard status before including any associated downtime in a repair-cost estimate.