Introduction

Miner uptime is the percentage of a measured period during which a miner is operating. In Bitcoin pool mining, useful operation means an ASIC is hashing and connected to the pool so it can submit shares. When it goes offline, it loses opportunities to contribute work and earn mining rewards.

Uptime alone does not show how well a miner is performing. A machine can remain online while a faulty hashboard reduces its hashrate or connection problems cause shares to be rejected. Understanding mining performance therefore requires looking at uptime alongside hashrate and share acceptance.

The goal is to maintain reliable operation when mining is economically justified, while distinguishing planned shutdowns from equipment or network failures.

How Uptime Affects Expected Mining Earnings

In pooled mining, a miner demonstrates work by submitting shares: proof-of-work results that meet the pool-assigned share target, which is easier to satisfy than the Bitcoin network’s block target. Pools use contributed work to calculate rewards under their payout rules. An offline miner submits no new shares during that interval.

For a basic time-based calculation:

Uptime (%) = operating time ÷ total observation time × 100

Over a 30-day month, the total observation time is 720 hours:

• At 99% uptime, downtime totals 7.2 hours.
• At 95% uptime, downtime totals 36 hours.

For these examples, downtime includes all time the miner is not operating, including planned shutdowns. Record planned curtailment and unplanned outages separately so the total does not hide their different causes.

At unchanged hashrate and expected earnings per operating hour, 1% less operating time means approximately 1% less expected mining earnings compared with continuous operation over the same period. This is a useful estimate, not a guarantee about realized payouts. Network difficulty, transaction fees, pool fees, and the payout method can affect the earnings associated with a particular outage.

Lost mining earnings and the net financial impact are different measures. An outage may avoid some electricity costs, but those savings do not reduce the amount of BTC mining earnings forgone. To estimate the net financial impact, compare forgone earnings and avoided operating costs in the same currency over the same period, against the scenario in which the miner kept operating.

Bitcoin targets an average block interval of approximately 10 minutes; blocks do not arrive on a fixed schedule. Difficulty adjusts every 2,016 blocks using elapsed block time. Neither mechanism awards a miner credit for work it missed while offline (Bitcoin Developer Guide).

A Miner Can Be Online Without Producing Normal Work

Uptime, hashrate, and rejection rate answer different questions:

• Uptime: How much of the observation period was the miner operating?
• Hashrate: How much hashing work was it performing, or how much does the pool estimate from its shares?
• Rejection rate: What proportion of submitted shares did the pool reject, according to its reporting method?

A miner with a faulty hashboard may remain online and submit accepted shares while producing less work than expected. Another miner may show normal local hashrate but have fewer shares accepted because of connection problems. Neither situation is fully explained by uptime alone.

Common causes of reduced mining output or rejected shares include unstable connectivity, overheating, fan or hashboard faults, unstable tuning settings, firmware problems, and power delivery issues. These problems do not all produce the same symptoms: hardware faults can reduce hashrate without increasing rejection rate.

Stale, invalid, and duplicate submissions are possible reasons for rejection. A stale share can result when work is no longer current by the time the pool receives it. Some rejected shares can occur during normal operation, so look for a persistent or rising rejection rate and review the available rejection reasons alongside miner logs.

Compare Local and Pool Hashrate Carefully

A miner’s local interface reports hashing activity from the device. A pool estimates hashrate from submitted work over its reporting window. These readings can differ because of their measurement methods, averaging periods, and short-term variation in share submissions.

ViaBTC calculates its real-time hashrate using the previous 10 minutes, while its daily statistic covers the previous 24 hours (ViaBTC Help Center). A miner that recently restarted may therefore display a normal current local reading while its pool-side daily average still reflects the earlier downtime.

Before treating a discrepancy as a hardware problem, check which periods the readings cover and whether a restart, reconnection, or increase in rejected shares explains the difference. Compare equivalent windows where possible and investigate persistent gaps rather than reacting to one short-term reading.

Why Fresh Work and a Stable Connection Matter

Miners need fresh pool jobs when the work changes, particularly when a new block changes the chain tip. Delays in receiving updated work or submitting shares can leave a miner working on an outdated job, leading to stale submissions even when the ASIC itself is functioning correctly (Bitcoin Developer Guide).

Check the connection between the miner and the pool, including cables, switches, and the internet connection. When selecting among supported pool endpoints, consider observed latency, connection stability, and rejection patterns over time. Geographic proximity alone does not establish which connection will perform best.

Planned Curtailment Is Different From a Failure

Some operators intentionally reduce or stop mining when electricity prices make continued operation uneconomic or when participating in grid-related curtailment. This differs from an unexpected hardware or network failure.

For a short-term operating decision, compare expected mining revenue with the costs that can actually be avoided by shutting down over the same interval. A change in BTC price changes the fiat value of expected BTC earnings; it does not, by itself, change how much BTC the miner produces.

Planned curtailment still reduces operating time when uptime is measured across the full period. Recording it separately from unplanned downtime makes the figure more useful: a lower percentage may reflect an intentional decision, a reliability problem, or both.

Payout Methods Do Not Replace Missing Work

A pool’s payout method determines how contributed work translates into rewards and how variable those rewards are. It does not generate shares for time spent offline.

ViaBTC documents two payment methods:

• PPS+: The block subsidy component uses PPS, while the transaction-fee component uses PPLNS.
• PPLNS: Both the block subsidy and transaction fees use PPLNS.

For its PPLNS calculation, ViaBTC documents a user’s share of pool hashrate over the last five difficulty rounds, with calculation when the relevant block completes six confirmations (ViaBTC Help Center).

A miner may still receive rewards after going offline because earlier contributions remain eligible or settlement occurs later. That does not mean the pool is paying for the offline interval. Switching payout methods can change reward timing and variability, but it cannot replace work that was never submitted.

How to Monitor Miner Uptime

A small set of checks can help operators notice problems and identify their likely cause:

1. Worker status: Check whether the pool reports the worker as online or offline, allowing for its reporting interval.
2. Pool-side hashrate: Look for sustained changes and compare with local readings over comparable periods.
3. Rejection rate: Review persistent increases and the rejection reasons where available.
4. Hardware condition: Check miner logs, temperatures, fan speed, and hashboard status.
5. Connection stability: Investigate repeated disconnects and problems with cables, switches, or the pool connection.

ViaBTC supports Watcher URL alerts in the ViaBTC App after the relevant alert settings are enabled. Its documentation specifies worker-offline checks every 10 minutes and rejection-rate checks every hour. Notification frequency and Do Not Disturb settings also affect delivery, so these alerts should not be treated as instantaneous detection (ViaBTC Watcher alert guide, alert upgrade announcement).

Alerts help bring problems to an operator’s attention. Diagnosing the cause still requires checking the miner, its connection, and any planned shutdown activity.

Conclusion

Miner uptime matters because time offline means fewer opportunities to contribute work and earn Bitcoin mining rewards. Under otherwise unchanged conditions, less operating time reduces expected mining earnings roughly in proportion to the time lost.

Read uptime alongside hashrate and rejection rate to understand actual performance. Track planned curtailment separately from failures, compare local and pool readings over similar periods, and investigate sustained changes in worker status or hardware condition. These practices help operators maintain reliable mining activity and identify avoidable losses.

FAQ

Does 100% uptime guarantee maximum mining revenue?

No. An online miner can operate below its normal hashrate or submit rejected shares. Network difficulty, transaction fees, pool fees, and the payout method also affect mining earnings.

Does 1% downtime mean 1% less mining revenue?

Approximately, if hashrate and expected earnings per operating hour remain unchanged and the comparison is against continuous operation over the same period. Realized payouts can differ, and avoided electricity costs affect net financial impact rather than lost BTC earnings.

Why does my miner’s local hashrate differ from the pool dashboard?

The readings use different measurement methods and may cover different periods. Pool estimates also fluctuate with share submissions. Check averaging windows, recent restarts, connection interruptions, and rejected shares before assuming a hardware fault.

Is a small number of rejected shares a problem?

Occasional rejections can occur during normal operation. A persistent or increasing rejection rate, especially alongside connection or hardware symptoms, is more useful for identifying a problem.

Does switching payout methods reduce the impact of downtime?

Switching can change payout timing and variability, but it cannot replace missing work. Rewards received after a miner goes offline may relate to earlier eligible contributions.

Is planned curtailment counted as downtime?

Yes, when uptime is measured across the full observation period. Record planned curtailment separately so it can be distinguished from unplanned equipment or network outages.

References

• Bitcoin Developer Guide: Block Chain
• Bitcoin Developer Guide: Mining
• 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?
• ViaBTC Help Center: How to Set Alerts in the Watcher URL?
• ViaBTC Help Center: Announcement on Hashrate Alert Feature Upgrade