APP
How to Use Hashrate Alerts to Catch Beginner Setup Problems
2026-09-07 16:17

Introduction

A hashrate alert does not fix a miner. It tells the operator that a mining pool is no longer receiving the amount of work it expects from a worker or account, based on the pool's own measurement window. For a newly configured ASIC, this distinction matters: the first hours after setup are when configuration typos, loose cabling, and unstable settings are most likely to surface, and an alert is often the first signal that something needs attention.

This guide focuses on three alert signals that are most relevant to a beginner setup — worker-offline status, hashrate drops, and elevated rejection rates — and how each one helps narrow down the likely cause. It does not cover profitability calculations or general ASIC maintenance, which are separate topics.

Start With the Right Comparison

A miner's local display and a pool's hashrate estimate are two different measurements. The miner reports what the device itself is calculating. The pool estimates hashrate from the valid shares it has received over a defined period. If shares are delayed, rejected, or not reaching the pool, the two figures will diverge even when the hardware is functioning normally.

ViaBTC documents this explicitly: its real-time pool hashrate is calculated from the previous 10 minutes, while its daily hashrate figure represents an average over the previous 24 hours (ViaBTC support). A miner that has been running for only a few minutes will not yet have produced a representative 24-hour average, so comparing a fresh setup against the daily figure will almost always look wrong. The correct comparison depends on how long the worker has actually been running: use the real-time figure for a recently started worker, and reserve the daily figure for a worker that has already been stable for a full day.

This is also why ViaBTC recommends observing a newly started worker for roughly 10 to 20 minutes, depending on its hashrate, before treating a low or missing pool-side reading as a fault (ViaBTC support). This guidance describes ViaBTC's own operational recommendation rather than a fixed rule that applies identically to every pool or every miner model.

Use the Three Alert Signals That Matter for a New Setup

Mining pools can surface different kinds of status changes through their alert systems, but the exact settings and delivery paths vary by feature. ViaBTC, for example, provides hashrate and rejection-rate notifications through its alert settings, while worker-offline and abnormal rejection-rate alerts are also available through its Watcher URL feature. Depending on the feature used, notifications can be delivered through channels such as email, App push notification, or Telegram (ViaBTC support).

For a new setup, three signals are especially useful:

  • Worker-offline alert — indicates that the pool is no longer seeing normal mining activity from the worker.
  • Hashrate-drop alert — triggers when the pool-estimated hashrate falls below a configured level.
  • Rejection-rate alert — triggers when the proportion of rejected shares exceeds a configured level.

ViaBTC's App Watcher URL feature includes alerts for worker-offline status and abnormal rejection rate; its documentation states that the offline check runs every 10 minutes and the rejection-rate check runs every hour (ViaBTC support). These intervals are useful to know because they set a realistic expectation: an offline notification through this feature is not instantaneous, and a brief connection blip may resolve before the next check runs.

What Each Alert Type Usually Means

An alert narrows the search for a cause; it does not identify the cause by itself. The following mappings describe common associations, not fixed diagnoses.

Worker Offline

An offline status means the pool is no longer seeing normal mining activity from that worker. The cause can sit at several layers, including configuration, network connectivity, power, or the miner itself. ViaBTC's troubleshooting guide lists incorrect pool URL, worker ID, password, or mining-software settings among the typical causes, while also covering situations such as network interruptions or an idle miner (ViaBTC support).

For a newly configured machine, the first check should still be a character-for-character comparison of the configured pool address, port, and worker name against the current setup instructions for the coin being mined. If those settings are correct, move outward to the network path, power state, and miner status rather than assuming the alert has already identified the faulty component.

Hashrate Drop

A drop in pool-estimated hashrate while the worker remains listed as online should first be checked against the pool's measurement window. Because pool-side hashrate is estimated from shares received during that period, short-term fluctuations can occur even when the miner's local display appears stable. A recently started or restarted worker may therefore need more time before the pool-side figure becomes representative.

If the lower reading persists beyond the expected measurement window, several causes become more plausible: intermittent network connectivity, a partial hardware issue on one hashboard, overheating, or an unstable custom frequency or voltage setting. Because several causes can produce the same symptom, a hashrate-drop alert should prompt a check of both the miner's local status page and its recent settings history before concluding that hardware has failed.

High Rejection Rate

Rejected shares are the broad category; stale shares, duplicate shares, low-difficulty shares, and other invalid submissions are different rejection reasons and should not be treated as interchangeable. A stale share is typically associated with work submitted after the pool has already moved to a new job, which can be affected by network latency or connection quality.

Other rejection reasons should be investigated according to the specific message shown in the miner or pool logs. Duplicate or low-difficulty submissions, for example, do not carry the same meaning as stale shares and may require checks of firmware behavior, mining settings, or hardware stability rather than a latency-only diagnosis. ViaBTC's rejection-rate guidance associates network conditions, overheating, and firmware issues with elevated rejection rates, and describes a rejection rate within 3% as within its normal range for its own platform — a ViaBTC-specific reference point rather than a universal industry threshold (ViaBTC support).

A Short Response Checklist

When any of these alerts fires on a recently configured miner, a short sequence of checks is usually more productive than immediately changing multiple settings:

  1. Confirm the exact status: offline, online with reduced hashrate, or online with elevated rejections.
  2. Check the configured pool URL, port, worker name, and password against current setup documentation.
  3. Review the miner's local status page for connection status, error messages, and hashboard or chain status.
  4. Check the physical network path: Ethernet cable, switch port, router, and the miner's assigned IP address.
  5. Check temperature and fan operation, and note any recent frequency, voltage, or firmware changes.
  6. Allow the pool's stated measurement window to pass before judging whether a low reading is a persistent problem or a transient one.

Changing only one variable at a time makes it possible to identify which correction actually resolved the alert.

Example. A newly configured ASIC shows normal hashrate on its local display, but the pool dashboard remains near zero after the expected measurement period and then reports the worker offline or below the configured hashrate threshold. Reviewing the miner log shows repeated reconnect attempts. The operator finds a loose Ethernet connection, reseats it, and the pool-side hashrate estimate returns to the expected range over the next measurement window. This sequence illustrates the core lesson: local hashing, share submission, and the pool's displayed estimate are related but distinct, and an alert is the trigger for checking each one in turn.

Avoiding False Alarms

A few habits help prevent misreading a normal, short-term variation as a fault:

  • Do not compare a miner that started minutes ago against a 24-hour pool average; use the shorter real-time window instead, and wait for the recommended initial observation period.
  • Do not treat a single rejected share as evidence of a hardware failure; investigate a sustained pattern instead.
  • Do not change several settings simultaneously in response to one alert, since doing so makes it difficult to identify which change actually resolved the issue.

Hashrate alerts reduce the time between a setup mistake and the first investigation. They do not diagnose the cause on their own, and they do not guarantee that downtime or lost shares will be avoided; their value is in shortening the interval before a miner operator notices that something needs to be checked.

FAQ

How quickly should I expect a hashrate alert after a real problem occurs?

This depends on the alert type and the pool's check interval. For example, ViaBTC's Watcher URL feature checks worker-offline status roughly every 10 minutes and rejection rate roughly every hour, so an alert reflects the pool's most recent check rather than an instantaneous event.

My local hashrate looks normal, but the pool shows a lower number. Is this always a problem?

Not necessarily. Pool-side hashrate is an estimate derived from shares received over a defined window, so short-term differences from the local reading are expected. Compare the pool's real-time figure for a recently started worker, and the daily figure only once the worker has been stable for a full day.

Should I treat every rejected-share notification as a hardware failure?

No. A rejected share can result from network latency, stale work, firmware or settings issues, or an underlying hardware problem. Check the specific rejection reason where available and look for a sustained pattern before assuming a hardware fault.

Can I rely on alerts alone to diagnose a setup problem?

An alert indicates that something has changed from the expected state; it does not identify the cause. Diagnosis still requires checking the miner's configuration, local status page, network connection, power state, and physical operating conditions.

References

Prev
What Liquidation Risk Means for Crypto-Collateralized Miner Loans
Next
How to Build a Simple Bitcoin Mining Pool Comparison Spreadsheet