What Hashrate-Weighted Uptime Measures

Hashrate-weighted uptime is a fleet availability calculation that weights each ASIC's online time by its hashrate rather than treating every machine as a single interchangeable unit. It measures reference-hashrate-weighted online availability: the proportion of the fleet's reference hash-time associated with online status during a chosen period. It does not account for reduced performance while a miner is online.

To calculate it, multiply each ASIC's reference hashrate by its online time, add the results, divide by the sum of each ASIC's reference hashrate multiplied by the full measurement period, and multiply by 100.

This article uses hashrate-weighted uptime as an explicitly defined fleet availability calculation. Operators should state the formula, reference hashrates, and online-status rule when reporting it, alongside measurements such as local hashrate, pool-estimated hashrate, and rejection rate.

Why Device-Count Uptime Misleads in a Mixed Fleet

A simple uptime rate based on device count — for example, "18 of 20 miners online" — treats every ASIC as equally important. In a homogeneous fleet of identical machines, that approximation is reasonable. In a mixed fleet containing, say, 250 TH/s and 50 TH/s units, it is not: an offline high-hashrate machine removes far more hashing capacity from the fleet than an offline low-hashrate machine, even though both count as "one unit down."

Consider two outage scenarios with the same total duration exposure. If a single 250 TH/s ASIC is offline for four hours, the lost hash-time is 250 × 4 = 1,000 (TH/s)·h. Five 50 TH/s ASICs would need to be offline for four hours each to lose the same 1,000 (TH/s)·h (5 × 50 × 4 = 1,000). A device-count uptime figure would report these two scenarios very differently — one unit down versus five units down — even though the hashing capacity lost to the fleet is identical. Hashrate weighting resolves this by expressing availability in hash-time rather than device-time.

The Formula

For a fleet of n ASICs observed over the same period T, hashrate-weighted uptime is:

Hashrate-weighted uptime (%) = [ Σ ( Href,i × t_online,i ) ] ÷ [ Σ ( Href,i × T ) ] × 100

Where:

• Href,i = the reference hashrate assigned to ASIC i, in TH/s
• t_online,i = the time ASIC i was online during the period
• T = the total measurement period, consistent for every ASIC
• n = the number of ASICs included

Both numerator and denominator multiply hashrate by time. With hashrate in TH/s and time in hours, the units are (TH/s)·h; they cancel in the ratio, which is then multiplied by 100 to give a percentage.

An equivalent form uses each machine's individual uptime fraction, Ui = t_online,i ÷ T. Enter Ui as a value from 0 to 1—for example, 23/24 ≈ 0.9583, not 95.83:

Hashrate-weighted uptime (%) = [ Σ ( Href,i × Ui ) ] ÷ [ Σ Href,i ] × 100

This is a weighted average in which higher-hashrate machines contribute more to the fleet-level result than lower-hashrate machines.

Worked Example

Assume a 24-hour measurement period and three ASICs:

The maximum possible hash-time for the period is (200 + 100 + 50) × 24 = 8,400 (TH/s)·h. Hashrate-weighted uptime is therefore 7,200 ÷ 8,400 × 100% = 85.71%.

For comparison, a simple average of the three individual uptime figures is (95.83% + 83.33% + 50.00%) ÷ 3 = 76.39%. That figure gives Miner C — a 50 TH/s unit — the same influence on the result as Miner A, a 200 TH/s unit. For a mixed fleet, it does not represent reference-hashrate-weighted online availability, which is what the hashrate-weighted figure is designed to show.

Choosing a Reference Hashrate

The calculation requires one consistent basis for Href across the full reporting period. Three approaches are common in practice.

Manufacturer-rated hashrate uses each model's nameplate specification. This is appropriate for estimating planned availability or comparing against an installed fleet plan, particularly when machines run close to stock settings. Its main limitation is that rated hashrate does not necessarily reflect a given unit's actual firmware, power mode, or environmental derating.

A documented local measured baseline uses a site-specific figure recorded for each device or model under its intended operating configuration. This approach is more appropriate when miners are underclocked, overclocked, or run in multiple power modes, or when the objective is to measure availability against normal site operation rather than nameplate capacity. The baseline should be held constant for the full reporting period; changing it mid-period without separating the periods makes month-to-month comparisons unreliable.

A time-varying reference hashrate is appropriate where operating modes change intentionally during the reporting period. In that case the calculation should be performed by interval:

Hashrate-weighted uptime (%) = [ Σi Σk ( Hi,k,ref × si,k × Δtk ) ] ÷ [ Σi Σk ( Hi,k,ref × Δtk ) ] × 100

Where Hi,k,ref is the selected reference hashrate for ASIC i during interval k, si,k equals 1 when the ASIC is online and 0 when offline, and Δtk is the interval duration. This prevents a unit's current configured hashrate from being incorrectly applied to a period when a different setting was in effect.

Defining "Online": Data Sources and Their Limits

The calculation needs an explicit, documented rule for what counts as "online" before it is applied. Several data sources can inform that rule, and each observes something different.

ASIC or farm-management telemetry shows device connection status, local hashrate, temperature, and board-level data, but a connected machine may still be underperforming rather than fully productive. Power-monitoring data shows whether a miner or circuit is drawing power, but power draw alone does not confirm productive hashing. Pool dashboards show shares received, pool-estimated hashrate, and rejection data, but these figures are share-based and subject to the pool's own averaging window. Worker-offline alerts flag the loss of normal activity under the pool's alert logic, but the alert timing is not necessarily the exact start of the outage.

As a general practice, miner or management-system telemetry is the more direct source for status-based uptime, since it reflects device state rather than an averaged estimate derived from share arrivals. Pool data is better used as a cross-check for whether submitted work is reaching the pool, a distinction explained further below.

Uptime Is Not the Same as Hashrate Performance

A miner can be online for an entire period while still underperforming due to thermal throttling, a degraded hashboard, or an unstable tuning profile. For example, a 200 TH/s ASIC that stays connected for all 24 hours but averages only 160 TH/s locally has a status-based uptime of 100%, even though its local hashrate is only 80% of its selected 200 TH/s reference.

For this reason, actual measured local hashrate should not be substituted into the uptime formula's numerator, since doing so changes what the metric represents. A separate comparison — local hashrate measured against the reference baseline — can be useful for capturing both downtime and derating together, but it should be labeled as such rather than reported as uptime.

Pool Hashrate as a Cross-Check, Not a Replacement

In pooled mining, a pool estimates a worker's or account's hashrate from the shares it receives, using a share target that is easier to meet than the Bitcoin network's block target, which is what allows miners to submit shares frequently enough to be measured (Bitcoin Developer Guide). That estimate reflects work reaching the pool over its stated window; it is not a direct, continuous measurement of device status.

ViaBTC's Help Center documents that its real-time hashrate figure is calculated from the preceding 10 minutes, while its daily hashrate figure is calculated from the preceding 24 hours (ViaBTC Help Center). For a useful cross-check, use pool data covering the same fleet and exactly the same start and end times as the uptime calculation, with the time zone stated explicitly. A calendar-day uptime report does not necessarily align with a rolling previous-24-hour pool reading; use aligned historical pool data where available. Even with matching windows, interpret the measurements together for diagnosis rather than directly comparing their numerical values: uptime is a status-based availability percentage, while pool hashrate is a share-based estimate expressed in hashrate units. The same documentation notes that network latency, rejection rate, hardware configuration, and firmware compatibility can all contribute to a gap between pool-reported and local hashrate readings, which is a separate diagnostic question from uptime itself.

Rejected shares should be reviewed alongside uptime but should not be subtracted from a status-based uptime figure, since rejections concern work submitted to the pool rather than whether the miner was online under the chosen operating definition. Where pool-side notifications are used — ViaBTC documents configurable hashrate and rejection-rate alerts with delivery through email, app push, and Telegram, along with worker-offline alerts (ViaBTC Help Center) — these are best treated as monitoring signals that prompt investigation, not as a substitute for timestamped fleet telemetry.

Common Calculation Errors

Several errors recur when this calculation is applied in practice:

• Giving each ASIC equal weight regardless of its hashrate, which reintroduces the device-count problem the calculation is meant to avoid.
• Mixing rated hashrate and measured local hashrate across different machines without labeling which baseline was used for each.
• Using pool data for a different fleet or time window, including a rolling 24-hour reading that does not align with the uptime report’s start and end times.
• Treating a short-term pool-side hashrate fluctuation as proof of device downtime without checking local telemetry.
• Counting a connected but clearly derated ASIC as offline, or vice versa, without a documented rule for what "online" means.
• Subtracting rejected shares from the uptime figure and then separately treating low pool hashrate as an additional downtime deduction, which double-counts the same underlying issue.
• Combining workers that changed operating mode or reference hashrate mid-period without calculating by interval.

FAQ

Is hashrate-weighted uptime an official mining-pool metric?

Here, the term refers to the fleet availability calculation defined in this article, rather than an official metric attributed to a particular pool. Any report using it should state its formula, reference hashrates, and online-status rule explicitly.

Can pool-estimated hashrate be used instead of ASIC telemetry to calculate uptime?

Pool-estimated hashrate reflects shares received over the pool's stated window and is useful as a cross-check, but it is not equivalent to device status and should not be relabeled as uptime.

Should rated or measured local hashrate be used as the reference value?

Either can be used, provided the choice is documented and held constant for the reporting period; measured local baselines are generally more representative when miners run outside stock settings.

What happens if an ASIC's operating mode changes during the reporting period?

The interval-based version of the formula should be used so that each configured hashrate value is applied only to the time it was actually in effect.

Does a high rejection rate mean the fleet has low uptime?

Not directly. Rejection rate concerns the outcome of submitted shares, while uptime concerns device online status; both should be reviewed, but one should not be derived from the other.

References

• Bitcoin Developer Guide, "Mining," developer.bitcoin.org — https://developer.bitcoin.org/devguide/mining.html
• ViaBTC Help Center, "Why is the Hashrate Shown in the Mining Pool Lower than that of the Mining Machine?" — https://support.viabtc.com/hc/en-us/articles/7574354263183-Why-is-the-Hashrate-Shown-in-the-Mining-Pool-Lower-than-that-of-the-Mining-Machine
• ViaBTC Help Center, "How to Set Hashrate or Rejection Rate Notification" — https://support.viabtc.com/hc/en-us/articles/7207414336143-How-to-Set-Hashrate-or-Rejection-Rate-Notification