Measuring downtime and lost mining production
Separate planned stops, faults and missing data so availability reports support real operational decisions.
ASIC.tools · Reviewed
Define what counts as available
Choose whether the report measures powered time, local hashing or accepted work reaching the pool. These states are not identical. A fan-running miner can be producing nothing, while a monitoring gap can occur when mining is still healthy. State the definition at the top of the report. Use a consistent reporting window and time zone, particularly when combining local equipment logs with an operator dashboard.
Classify each interruption
Record start, end, affected assets and cause where known. Separate planned maintenance, electrical outages, network loss, hardware faults and economic shutdowns. Keep unknown causes explicitly unknown until evidence resolves them. Avoid counting a shared incident once for the site and again as an additional independent loss on each rack. Device-level records can be aggregated, but the same missing production must not be added twice.
Calculate availability consistently
For an illustrative 24-hour observation window with two hours of lost accepted production, productive availability is 22 divided by 24, or about 91.7%. If planned maintenance is excluded from a contractual metric, show that adjusted metric separately rather than silently changing the denominator. A device with missing observations should not automatically be counted as fully healthy. Report data coverage alongside availability so readers can judge the result.
Estimate loss with dated assumptions
Use a documented revenue rate for the relevant period and device, then subtract costs actually avoided during the outage when estimating lost contribution. A fully powered-down unit may save energy; a stalled machine may not. Future returns are not needed to explain a historical incident. Label the result as an estimate and keep gross missed revenue separate from net operational impact and any repair expenditure.
Turn the report into a repair priority
Compare recurring incidents, time to detection and time to recovery. A frequent short network failure can matter more than a dramatic one-off event. Prioritize changes that address the underlying shared cause and measure the result afterward. Keep planned economic shutdowns separate from preventable faults. The report should explain where productive time went and which action could recover it, rather than only showing a percentage without an operational response.
