Introduction

A miner operator who checks a mining pool dashboard and sees a lower hashrate than the miner's own display often assumes something has failed — the ASIC, the network, or the pool itself. In practice, a mismatch between local hashrate and the figure shown on a pool dashboard does not automatically indicate a hardware fault. The two readings are produced by different systems, over different measurement windows, using different data. Local hashrate is an estimate calculated by the mining device itself, based on the work it believes it is performing. Pool-side hashrate is calculated from the shares the pool has actually received and accepted within its own reporting period. Before troubleshooting hardware, an operator should first confirm that the two figures are even being compared on equal terms.

This article outlines a structured way to diagnose the gap: start with the measurement window, then check whether shares are reaching and being accepted by the pool, then inspect the connection, and only then examine the miner itself.

Why the Two Readings Can Diverge

In pooled mining, a miner does not report its hashrate to the pool directly. Instead, it repeatedly attempts to find a hash below a target value and submits any result that meets the pool's share target as a "share." The pool assigns an easier target than the Bitcoin network's block target so that a miner can submit shares frequently enough to demonstrate a consistent contribution of work, as described in the Bitcoin Developer Guide's mining documentation (Bitcoin Developer Guide: Mining). The pool then estimates hashrate from the volume and difficulty of the shares it receives and accepts over a given window — not from any direct reading of the ASIC's internal chips.

This distinction matters because ViaBTC's real-time pool hashrate reflects an average over the prior 10 minutes, while its daily hashrate statistic reflects an average over the prior 24 hours. A miner's local display, by contrast, may refresh far more frequently — ViaBTC notes intervals as short as 5 seconds on some devices — and may represent a running average calculated over several days of operation (ViaBTC Help Center). A miner that restarted an hour ago can show a normal local figure almost immediately, while the pool's 24-hour statistic remains suppressed by the earlier downtime it still includes.

Step 1: Compare Matching Time Windows

Before assuming a fault exists, confirm that the comparison itself is valid. This means checking the same worker (not only the account total), the same coin, and a compatible time window on both sides.

If the pool's real-time 10-minute hashrate is low while the 24-hour average remains closer to normal, the drop may be recent and not yet fully reflected in the daily average. The reverse pattern means something different: if the real-time figure has recovered but the daily average remains low, the miner may have stabilized after an earlier interruption, while the 24-hour figure continues to reflect that downtime until it rolls out of the averaging window.

Allow the miner time to reach a steady state after any restart or configuration change. ViaBTC's BTC mining guidance suggests checking operating status after roughly 10–15 minutes, while its hashrate troubleshooting guidance notes that some models may require around 30 minutes to reach normal hashrate after a reboot (ViaBTC BTC Mining; ViaBTC: How to Stabilize the Hashrate?). This is operational guidance for ViaBTC's platform rather than a universal commissioning standard, and actual stabilization time varies by device and firmware.

Only once the comparison uses matching workers and compatible windows — and enough time has passed for the miner to stabilize — does a persistent gap become meaningful.

Step 2: Confirm Shares Are Reaching and Being Accepted by the Pool

A miner can appear to be hashing normally at the device level while its submitted shares are delayed, rejected, or fail to reach the pool reliably. This is a core reason a local reading and a pool reading can diverge even when the ASIC's local display appears normal.

Start by checking the worker's status on the pool dashboard — whether it shows online, offline, or intermittently inactive — and review the account's rejected-share figures. A rejected share is a submission that reaches the pool but is not accepted; where the dashboard provides a reason code, review it rather than assuming a single cause. ViaBTC's own troubleshooting guidance treats a rejection rate within roughly 3% as its stated normal range for its platform; this is ViaBTC-specific operational guidance rather than an industry-wide benchmark, and rejection behavior can vary by pool and connection quality (ViaBTC Help Center).

A rising rejection rate alongside a falling pool-side figure can point to connection problems, configuration errors, or miner-side instability. Rejection reasons, connection status, and miner logs should be considered together before assigning the problem to a single layer.

Step 3: Inspect the Mining Connection

If shares are being lost, delayed, or rejected, the mining connection is the next place to check:

• Confirm the Stratum URL and worker name match the pool's current configuration. On ViaBTC, workers use the userID.workerID format; the password is optional.
• Verify the miner has not been redirected to a different pool, account, or sub-account, which would explain activity disappearing from the expected dashboard view.
• Check local network equipment — routers, switches, cabling, and network interfaces — for instability or high latency, which ViaBTC identifies as a common cause of a widening gap between local and pool-side readings.
• Where the pool supports multiple connection ports or backup endpoints, confirm the miner is pointed at an active one.

A configuration mismatch (such as the wrong worker ID or account) and a network problem (such as an unstable connection) can produce the same visible symptom — a normal-looking local display alongside a depressed pool figure — so both should be checked before moving on to the hardware itself.

Step 4: Review Miner Health and Configuration

If the time window is matched, shares are reaching and being accepted by the pool with an acceptable rejection rate, and the connection is confirmed correct, the remaining candidates are the miner's own operating conditions:

• Temperature and throttling. Excessive heat can cause a miner to reduce its clock speed or intermittently restart hash boards, which can affect submitted work even if the local display has not yet reflected a sustained drop.
• Frequency and overclocking settings. Non-default frequency profiles can produce unstable output or increase invalid or rejected shares. The miner's displayed average may not immediately reflect a change in effective output seen by the pool.
• Firmware version. Outdated or incompatible firmware can create submission issues with a specific pool. Firmware should generally be updated only through the manufacturer's official channel.
• Physical faults. Loose cabling, a failing hash board, or intermittent chip errors can reduce actual output while a local average, calculated over a longer running period, has not yet caught up.

This step is placed last deliberately: opening a miner or changing firmware is a more disruptive action than checking a dashboard setting or a network cable, and it should follow — not precede — the earlier diagnostic steps.

Using Monitoring Tools to Reduce Diagnosis Time

Rather than relying on manual checks after the fact, ViaBTC allows users to configure hashrate and rejection-rate alerts, with delivery through email, app push notification, or Telegram, so that a sustained deviation can be investigated sooner rather than discovered during a routine check (ViaBTC Help Center). Alert thresholds should be set based on the operation's normal hashrate variation rather than a fixed industry figure, since acceptable fluctuation differs by device model and site conditions.

The Workers page also allows filtering for offline or inactive workers and exporting worker-level data, which is useful for isolating whether a discrepancy affects a single unit, a rack, or the account as a whole (ViaBTC Help Center). Isolating the affected scope early narrows the remaining troubleshooting steps considerably.

When to Contact Pool Support

If the gap between local hashrate and the pool dashboard persists after confirming a matched time window, reviewing rejected shares, checking the connection, and inspecting miner health, contacting support is a reasonable next step. Providing the worker name, the affected time range, the rejection-rate figures observed, and screenshots from both the miner interface and the pool dashboard allows a support team to investigate the specific discrepancy rather than a general symptom.

Conclusion

A lower pool-side reading alongside a normal-looking local display is a diagnostic signal, not proof of a single cause. Local hashrate and pool dashboard hashrate are calculated differently — one from the device's own estimate, the other from shares actually received and accepted by the pool within its reporting window — so a gap can arise from timing alone before any hardware or network issue is involved. Working through the checks in order — matching the comparison window, confirming shares are reaching and being accepted by the pool, verifying the connection, and only then inspecting the miner — avoids premature hardware changes and generally identifies the cause more efficiently than reacting to the dashboard number alone.

FAQ

Why does my miner show full hashrate but the pool shows less?

The two figures are calculated differently: the miner's local display is typically a device-side estimate refreshed frequently or averaged over its own running period, while the pool dashboard reflects shares actually received and accepted within the pool's reporting window (for example, a 10-minute or 24-hour average on ViaBTC). A recent restart, brief network interruption, or a still-recovering daily average can create a visible gap even when the miner is currently operating normally.

How long should I wait after a restart before troubleshooting?

Allow the miner time to reach a stable operating state before diagnosing a fault. As general guidance, ViaBTC's setup documentation suggests checking status after roughly 10–15 minutes, while its hashrate troubleshooting guidance notes that some models may require around 30 minutes; this is platform-specific guidance rather than a fixed rule, and actual timing depends on the device and firmware.

Does a high rejection rate always mean a network problem?

No. A rising rejection rate can be associated with connectivity or latency, but configuration errors and miner-side instability can also contribute. Where rejection reasons are available, review them together with the miner's connection status and logs before assigning the problem to the network alone.

Can I calculate my miner's efficiency from the pool dashboard hashrate?

No. Hardware efficiency figures such as J/TH require a measured power input matched to the same hashrate reading and time period. Pool-side hashrate estimates are not an appropriate substitute for device-level power and hashrate measurements.

Should I change firmware or overclock settings as a first step?

Generally no. Firmware and overclock changes are more disruptive than checking a dashboard setting, worker status, or network cable, so they are best considered after the connection and configuration have been ruled out.

References

1. 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
2. ViaBTC Help Center. "What if the Rejection Rate is High?" https://support.viabtc.com/hc/en-us/articles/7207400264591-What-if-the-Rejection-Rate-is-High
3. ViaBTC Help Center. "What Should I Do If It Shows Offline or Inactive Workers While The Miner Is Working?" https://support.viabtc.com/hc/en-us/articles/7207400997007-What-Should-I-Do-If-It-Shows-Offline-or-Inactive-Workers-While-The-Miner-Is-Working
4. 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
5. Bitcoin Developer Guide. "Mining." https://developer.bitcoin.org/devguide/mining.html
6. ViaBTC Help Center. "BTC Mining." https://support.viabtc.com/hc/en-us/articles/7207401012879-BTC-Mining
7. ViaBTC Help Center. "How to Stabilize the Hashrate?" https://support.viabtc.com/hc/en-us/articles/7207428288911-How-to-Stabilize-the-Hashrate