Mining downtime reduces time available to contribute work, but it does not necessarily reduce every expense by the same percentage. A device may be connected without hashing, or hashing without all its work being accepted. Define the operating state first, then compare time, contribution, energy and costs across the same period.
Uptime depends on its definition and denominator. Revenue examples hold other inputs constant.
BTKWIN.COM · EDUCATIONAL EXAMPLE1. Define uptime before calculating it
Uptime can mean time since the operating system restarted, connection to a management tool, active hashing or accepted pool contribution. Those states are related but distinct. The Braiins worker-details documentation presents hashing, connectivity and performance metrics separately, illustrating why one connection indicator cannot answer every question.
For revenue estimates, being powered does not establish continuous accepted work. For electricity estimates, an absence of hashing does not establish zero consumption. Record state durations where available and preserve an unknown category when monitoring data is missing. An interrupted monitoring connection does not prove either equipment downtime or continued production.
A simple time-availability proportion divides time in the defined state by the observation period. Productive operation for 21.6 hours of a 24-hour day gives 90%. If a report excludes scheduled maintenance or hours before installation from its denominator, state that explicitly. Changing the denominator can raise the percentage without adding productive time.
Use the full period or explain exclusions
A thirty-day teaching month contains 720 hours. Productive uptime of 90% means 648 productive hours and 72 hours outside that state. A 31-day month contains 744 hours, so the same percentage corresponds to 669.6 productive hours. Equal percentages do not establish equal quantities of time or work.
Suppose a contract report excludes 48 maintenance hours from a 720-hour month. Reporting 648 productive hours against the remaining 672 gives approximately 96.43%, while productive time across the whole month is still 90%. Both calculations can follow their definitions, but they should not be compared as interchangeable measurements.
| Illustrative reporting boundary | Denominator | Productive hours | Availability |
|---|---|---|---|
| Entire thirty-day month | 720 h | 648 h | 90% |
| 48 hours excluded | 672 h | 648 h | About 96.43% |
Do not double count overlapping events. A connection outage from 10:00 to 11:00 and a cooling event from 10:30 to 11:30 overlap. If production is unavailable throughout their combined span, the lost time is 1.5 hours, not two. Preserve both reason labels while calculating the union of affected intervals.
2. Separate operating time from output intensity
A device can hash throughout an hour at less than its reference rate. Time-based availability can therefore be 100% despite reduced work. Keep accepted hashrate or cumulative accepted contribution beside time. Converting every period with any nonzero output into full production can overstate an estimate based on nominal capability.
With a fictional 200 TH/s reference, twelve hours at 200 TH/s and twelve hours at 100 TH/s average 150 TH/s. The equipment was active throughout, but delivered 75% of the reference work over the day. That work ratio answers a different question from the proportion of hours without a complete stop.
If a pool’s full-day accepted average already includes downtime, multiplying it by 90% again can count the same lost time twice. If the figure is an active-only rate, an operating-time factor may be needed. Read the average’s definition before adding another deduction, particularly when importing values into a calculator.
3. Treat revenue estimates as conditional scenarios
If a fictional uninterrupted day’s revenue is ten currency units, a linear estimate at 90% productive time is nine when contribution rate, reward, price and fees are unchanged. That result is a scenario, not a pool entitlement. Payment rules, timing, network conditions and variation can make actual credited rewards differ.
If accepted performance during active time is also 5% below the reference, the combined factor is 0.90 multiplied by 0.95, or 0.855. The corresponding simplified revenue is 8.55. Adding a 10% time reduction and 5% performance reduction does not apply the same sequential relationship.
Timing can matter when reward conditions or electricity rates differ by hour. Ten productive hours during one period may not have the same cash effect as ten during another. Use interval-specific inputs if records support them. Otherwise describe the calculation as a constant-input approximation rather than an actual settlement.
4. Identify costs that continue during downtime
Consider a fictional miner drawing 3 kW while active and auxiliary equipment drawing a constant 0.5 kW. A full day consumes 72 plus twelve, totaling 84 kWh. If the miner is completely off for 10% of the day while support remains on, the components consume 64.8 and twelve kWh, totaling 76.8.
The site energy reduction is approximately 8.57%, not 10%, because the auxiliary component did not stop. If the event is only a connection loss and both loads remain unchanged, energy may remain 84 kWh while credited contribution falls. Do not automatically scale the entire electricity bill by the uptime percentage.
Rent, fixed service charges and some maintenance or finance costs can continue as well. With fictional revenue of ten and fixed costs of eight, the margin is two. Revenue falling to nine while costs stay eight reduces the margin to one: a 50% margin decline from a 10% revenue decline.
Record events and compare fleets with suitable weights
For each event, record start, end, affected state, known reason, action and the time accepted work resumed. Power restoration can precede startup, calibration or authorization. Do not automatically equate the end of a power outage with restored production, or assume every recovery minute has identical consumption without measurement.
Use practical reason categories such as power, connection, maintenance, temperature, configuration and unknown. Retain the underlying messages. When hosting is involved, read contractual availability definitions, exclusions and compensation terms separately. A service credit does not necessarily equal the revenue projected by your own model.
Fleet comparisons need appropriate weights. A 100 TH/s device active all day and a 300 TH/s device active half the day have a simple average time availability of 75%. Their work relative to the fully active 400 TH/s fleet is instead (100 + 150) divided by 400, or 62.5%.
Keep both measurements if they serve different operational questions. Include installation and removal dates so that devices are not assigned observation hours before joining the fleet or after leaving it. Accurate fleet scope matters as much as accurate time boundaries.
At each monthly review, reconcile time, accepted work, energy, credited rewards, payouts and expenses separately. The rejected-share guide helps interpret contribution differences. A useful downtime report explains what stopped, for how long and which costs continued, with uncertainty visible where records are incomplete.
Continue reading
English content and examples reviewed: 27 October 2026. Read the Arabic edition.
