What a mining pool uptime guarantee actually means
A mining pool uptime guarantee is a documented commitment that a specific pool service will be available for a stated percentage of a stated period. It is not a general assurance that a miner will always earn, nor a promise that every connected ASIC will stay online. Before a percentage figure has any practical value, the pool needs to define which service is covered, over what measurement window, using what method of measurement, which events are excluded, and what remedy applies if the commitment is missed.
What a mining pool uptime guarantee can cover
Depending on its terms, a mining pool uptime guarantee can cover the availability of the Stratum endpoint that accepts worker connections, the pool's ability to deliver current mining jobs and receive and validate submitted shares, or the availability of the account dashboard, API, or payment service. These functions are related but not interchangeable. A reachable dashboard does not confirm that shares are being accepted at that moment.
Reward calculation accuracy and payout deadlines are separate commitments to check. A payment service may be available without that fact alone establishing whether balances were calculated correctly or payments were completed on time.
Why uptime matters in pooled mining
Pooled mining follows a simple operational chain: the pool distributes mining work, the ASIC hashes locally against a pool-assigned share target, the ASIC submits shares back to the pool, and the pool validates those shares before applying its payout rules. The Bitcoin Developer Guide explains that shares provide statistical evidence of the work a miner has contributed and that pools use submitted shares to calculate each participant's portion of mining proceeds (developer.bitcoin.org). A share meets the pool's target, but it does not establish the exact number of hash attempts the miner made to find it.
If the connection between an ASIC and the pool is interrupted, the miner may be unable to receive new jobs or submit valid shares during that interval. The ASIC can continue consuming power without contributing accepted work to that pool for as long as the interruption lasts. This is why endpoint availability and the pool's ability to process submissions are central to any uptime discussion, rather than a secondary detail.
What an uptime guarantee does not automatically cover
A commitment to pool-service availability does not automatically cover ASIC hardware faults, local power loss, overheating, or site-level network failures. It also does not guarantee mining profitability, which depends on factors beyond service availability.
Readers evaluating an uptime claim should separate the following categories and check which ones the published terms actually address.
| Category | What it describes | Typical causes of disruption |
|---|---|---|
| Miner uptime | Whether the ASIC itself is operating | Power loss, overheating, firmware fault, hashboard failure |
| Site/network availability | Whether the miner can reach the internet and the pool endpoint | ISP outage, router failure, DNS issue, firewall rule |
| Pool connection availability | Whether the configured Stratum endpoint accepts and maintains a session | Endpoint, routing, port, or protocol problem |
| Pool service availability | Whether the pool can supply jobs, accept shares, and run covered functions | Pool-side infrastructure or backend disruption |
| Payout and settlement operations | Whether eligible balances are calculated and settled under the pool's rules | Accounting delay, blockchain confirmation time, payment processing |
A stated uptime percentage that covers only the website or API does not establish the availability of share processing or the timing of settlement. The payout and settlement row describes operations whose accuracy and deadlines should be assessed separately from uptime.
How to read an uptime commitment
Rather than treating any single percentage as self-explanatory, a documented commitment should be checked against the following points:
- Covered service: Does the figure apply to Stratum connectivity, the API, the dashboard, payment processing, or all of them together?
- Measurement window: Is it calculated monthly, quarterly, over a rolling 30 days, or some other period?
- Measurement source: Is availability derived from pool-side logs, independent monitoring, or customer-reported outages?
- Downtime definition: Does a partial or regional disruption count as downtime? Are failed share submissions counted?
- Exclusions: Are scheduled maintenance windows, DDoS mitigation, upstream network failures, or force majeure events excluded from the calculation?
- Remedy: Does the provider specify a service credit, fee adjustment, or other consequence if the commitment is missed?
- Claim process: Is there a defined window and evidence requirement for reporting a missed commitment?
The arithmetic behind a percentage is simple—availability equals the total period minus covered downtime, divided by the total period—but the result is only meaningful once these seven points are answered. As an illustration of what stated percentages permit in practice, a 99.9% figure corresponds to roughly 43 minutes of downtime in a 30-day month, while 99.0% permits roughly 7 hours 12 minutes in the same period. These figures are shown only to demonstrate the scale involved; they are not a claim about any specific pool's published terms.
Connection redundancy: useful, but not a guarantee
Connection redundancy can reduce the likelihood that an ASIC sits idle because of a single point of failure, but redundancy is a continuity measure, not an uptime guarantee in itself.
ViaBTC's current pool-information documentation lists several global BTC hostnames on port 3333, each paired with a failover port of 443, along with a Europe-oriented endpoint and separate SSL addresses (support.viabtc.com). Configuration options of this kind serve specific, narrow purposes:
- A backup port can allow a connection to succeed when the primary port is blocked by a local firewall or network filter.
- Multiple hostnames can give a miner an alternative route if one address becomes unreachable.
- Configuring a backup pool in mining firmware may reduce idle time if the preferred pool cannot be reached at all.
For example, a mining site that cannot reach the standard Stratum port because of a restrictive local firewall may be able to connect through ViaBTC's documented failover port 443 without switching pools. This addresses a specific connectivity problem.
Alternate hostnames or ports belonging to the same pool do not necessarily protect against an issue affecting its shared backend, accounting system, or settlement process. Failover options help an ASIC reach a working connection; they do not, by themselves, establish an availability commitment.
What miners should monitor alongside any uptime claim
Because pool-side availability and miner-side performance are measured separately, operators benefit from monitoring both sides of the relationship rather than relying on a single indicator. Relevant data points include the miner's local connection state and event log, local ASIC hashrate as reported by the device itself, the pool's estimated hashrate over a comparable time window, the count of accepted versus rejected shares, and the specific reasons for rejection where the pool reports them—stale shares being one common subcategory within the broader rejected-shares classification.
ViaBTC's documentation describes configurable alerts for hashrate drops and elevated rejection rates, delivered by email, app push notification, or Telegram, including notices when a worker goes offline (support.viabtc.com). These alerts help an operator detect an interruption more quickly than manually checking a dashboard, but an alert is a monitoring feature. It identifies that a condition has occurred; it does not prevent the underlying interruption or substitute for a documented availability commitment.
When the ASIC is hashing but the pool shows little activity
A common point of confusion arises when a miner's local dashboard reports normal hashing activity while the pool's statistics show little or no corresponding activity. The discrepancy can stem from an incorrect pool URL, a worker-naming error, a network path problem, or shares being rejected after submission. Local hashrate and pool-side hashrate estimates are measured independently and over potentially different windows; they should not be treated as a single figure, and a "running" status on the device does not by itself confirm that shares are being accepted.
Conclusion
An uptime claim becomes useful only when it specifies what is covered, over what period, measured how, with what exclusions, and remedied how. Evaluate that commitment alongside the pool's connection options and monitoring tools, while keeping miner health, settlement accuracy, and mining profitability separate from service availability.
Frequently asked questions
How is pool uptime typically measured?
It depends on what the pool defines as the covered service. A documented commitment should state whether it covers Stratum connectivity, share processing, the API, the dashboard, or payment-service availability, along with the measurement period and the source of the data used to calculate availability.
Does a backup pool setting protect against all downtime?
No. A backup pool configured in mining firmware can reduce idle time if the primary pool is unreachable, but it does not address ASIC hardware faults, local power loss, or site-level network failures.
If my ASIC shows it is hashing, does that mean the pool is receiving my shares?
Not necessarily. Local hashrate reported by the device and the pool's estimated hashrate are separate measurements. Discrepancies can result from configuration errors, network issues, or rejected shares, so both should be checked independently.
Are rejected shares the same as stale shares?
No. Rejected shares is the broader category; stale shares—submissions that arrive after the relevant work has expired—are one specific reason a share may be rejected, alongside other possible causes such as invalid or duplicate submissions.
Does an uptime guarantee cover mining profitability?
No. An uptime guarantee addresses the availability of a defined pool service. It does not account for Bitcoin price movements, network difficulty changes, electricity costs, or other factors that determine mining profitability.
References
- Bitcoin Developer Guide, Mining
- ViaBTC Help Center, Mining Pools Information
- ViaBTC Help Center, How to Set Hashrate or Rejection Rate Notification?