Introduction
To monitor multiple workers in one ViaBTC mining-pool account, give each miner a distinct worker ID, check its status and hashrate on Pool → Workers, filter for offline or inactive workers, and configure alerts for changes that need attention. Compare pool-side hashrate with local miner readings over matching time windows before diagnosing a fault.
An individual mining-pool account can host dozens of ASICs or mining instances simultaneously. Without a consistent monitoring approach, an operator managing several machines can lose track of which unit is online, which is underperforming, and which has stopped submitting work entirely. Worker groups, sub-accounts, Watcher URLs, and the API provide additional options when the operation needs more organization or shared monitoring.
What a Mining Worker Represents
In pool mining, a worker is an identifier used to label mining activity within an account. To monitor each machine separately, give each device or mining instance a distinct worker ID. If multiple devices use the same full worker identity, their activity can be aggregated under one dashboard entry.
For ViaBTC BTC mining, the full worker name follows the pattern userID.workerID, where the account portion identifies the pool account receiving credit for submitted work and the worker-ID suffix labels the device or mining instance. Changing only the suffix does not alter the miner's hashing performance or the account's payout method or withdrawal settings. Changing the account portion changes the account identifier under which the miner submits work. These distinctions are explained in ViaBTC's worker setup guide.
Workers are detected automatically once a miner is configured correctly and begins submitting shares; there is no need to pre-register a worker name in the dashboard before connecting the device.
Establish a Clear Worker-Naming Convention
Before connecting multiple ASICs, assign each one a distinct, descriptive worker ID that meets the naming rules for the coin being mined. For BTC, ViaBTC requires the worker-ID suffix to contain only lowercase letters and numbers and to be no longer than 64 characters. Hyphens are not permitted under these rules. See the ViaBTC Help Center BTC mining guide; for another coin, check its own official mining instructions.
A practical convention ties the dashboard label back to a physical location or asset. For example, these BTC worker IDs meet the documented character and length requirements:
sitearack02asic01
sitearack02asic02
sitebrack01asic01
For a small home setup, a simpler sequence such as asic01, asic02, asic03 is sufficient. Enter the chosen ID after your account identifier and the period separator, such as youruserid.sitearack02asic01, replacing youruserid with your actual account identifier.
Within the applicable naming rules, the convention is a matter of operator preference. What matters is that each worker can be mapped to a real machine when it appears offline or shows abnormal activity on the Workers page.
Monitor Workers From the Dashboard
After configuration, use the pool's Workers page as the first operational view. The dashboard lists each detected worker along with its status, real-time hashrate, and daily hashrate.
- Sign in to ViaBTC, confirm that you are viewing the intended mining account and coin, and open Pool → Workers.
- Find the expected worker IDs and check their status and hashrate. When each device uses a distinct worker ID, compare the active-worker count with the number of devices expected to be running.
- Use the status filter to find Offline or Inactive workers, then trace each affected ID back to its machine and check its local status.
ViaBTC documents status filtering in its offline-worker troubleshooting guide.
ViaBTC's Workers page also supports basic organization, including creating groups, moving selected workers into a group, and removing workers that have been inactive for an extended period (ViaBTC Help Center, worker management guide).
Understand Active, Offline, and Inactive Status
ViaBTC classifies each detected worker into one of three states:
- Active: the worker is connected and currently submitting shares.
- Offline: the worker has reported no hashrate for between 20 minutes and 1 day.
- Inactive: the worker has reported no hashrate for more than 1 day.
These definitions are specific to ViaBTC's dashboard and are not a universal mining-industry standard (ViaBTC Help Center, worker management guide). A worker shown as offline should be checked against the miner's own local status page, network connection, and power state before concluding that the hardware has failed; a brief disconnection, a router restart, or a firmware update can all produce a temporary offline status that resolves without intervention.
Local Hashrate vs. Pool-Side Hashrate
One of the most common sources of confusion in multi-worker monitoring is comparing a miner's local display directly against the pool dashboard. These are related but distinct measurements.
Local hashrate is the figure reported by the ASIC's own firmware or by mining software, based on the device's internal measurement of its hashing activity. Pool-side hashrate, by contrast, is an estimate derived from the accepted work represented by a worker's shares over a defined window, with each share's assigned difficulty determining the work it represents. ViaBTC calculates real-time hashrate as an average over the previous 10 minutes and daily hashrate as an average over the previous 24 hours (ViaBTC, pool hashrate and mining statistics guide).
Because pool-side hashrate is a rolling average based on submitted work, a newly started or recently restarted worker can show a lower daily figure simply because the 24-hour window still includes earlier idle time. Similarly, a short-term dip in the 10-minute real-time figure does not necessarily indicate a hardware problem; it may reflect normal variance in share submission timing. Operators should compare values using matching time windows — for instance, a 10-minute pool estimate against a similarly short-term local reading — rather than treating a brief divergence as proof of a fault.
Accepted and rejected shares provide an additional layer of information. A rejected share is one the pool did not credit; stale, invalid, and duplicate submissions are typically subcategories of rejected shares rather than separate top-level outcomes. Because pools can adjust the difficulty target assigned to a worker's shares, a raw count of submitted shares is not always directly comparable between two machines or two time periods unless the share difficulty and reporting window are equivalent.
Configure Alerts for Hashrate and Rejection-Rate Changes
For accounts with more than a handful of workers, continuous manual checking of the dashboard is impractical. ViaBTC allows users to configure notifications for hashrate changes, worker-offline events, and elevated rejection rates through email, app push notification, or Telegram, depending on the configuration.
To set up alerts through the website:
- Sign in to ViaBTC and open Pool → Dashboard → Alert Settings.
- Configure the available parameters for the alert you want to enable, then click Confirm.
- Under Notification Method, configure the receiving email address or Telegram account as applicable.
Follow the options shown for the selected alert and refer to the ViaBTC Help Center notification setup guide for the full workflow.
ViaBTC's September 2025 alert upgrade announcement specifies worker-offline checks every 10 minutes and worker rejection-rate checks every hour. These check intervals are separate from the configured notification frequency. Notifications follow that frequency, and a Do Not Disturb period can prevent alerts from being sent during the selected time range.
An alert therefore does not provide a guaranteed time from a device failure to notification: the condition must first qualify for an alert and be picked up by a periodic check. Operators should set thresholds that reflect their own equipment mix and operating pattern rather than assuming a single universal setting is appropriate for every configuration.
Organize Workers With Groups or Sub-Accounts
As the number of workers grows, two organizational tools can help structure monitoring, and they serve different purposes.
Worker groups organize miners within a single account for easier viewing — for example, separating workers by site, rack, or hardware model on the same Workers page. This is the appropriate tool when the goal is simply to make a long worker list easier to scan.
Sub-accounts, by contrast, create separate views of hashrate and mining income within the same ViaBTC login. ViaBTC's documentation describes sub-accounts as useful for separating distinct mining farms, authorized users, or groups of miners that require independent reporting (ViaBTC Help Center, sub-accounts guide). Sub-accounts are generally more relevant when an operator needs distinct income or hashrate reporting for different sites, clients, or operational units — not simply for organizing a small number of machines in one location.
Share Read-Only Access With a Watcher URL
In some operations, a technician, business partner, or co-owner needs visibility into worker status without the ability to change account settings or payout configuration. ViaBTC's Watcher URL provides read-only access to specified account information; the account owner can set viewing permissions when creating the link (ViaBTC Help Center, Watcher URL guide). Because a Watcher URL grants visibility into account activity, it should be treated as sensitive information and shared only with intended recipients.
Optional: Programmatic Monitoring via API
Operators running custom monitoring dashboards or larger numbers of workers may prefer to pull pool data programmatically rather than checking the web interface. ViaBTC provides API-key management with an IP-whitelist option, as explained in its official API setup guide. This path is optional and primarily relevant to operators who already maintain their own monitoring infrastructure; it is not a prerequisite for monitoring a modest number of workers through the standard dashboard. API keys and secret keys should not be shared, and unused keys should be removed when no longer needed.
A Practical Troubleshooting Sequence
When a worker shows abnormal status, a consistent investigation order helps avoid misdiagnosis:
- Confirm whether the dashboard shows the worker as active, offline, or inactive.
- Check the ASIC's local interface for power, network connection, pool connection status, local hashrate, and any reported hardware errors.
- Verify the pool address, port, account identifier, separator, and worker name against the documented format.
- Review accepted and rejected-share figures for the worker.
- Compare pool and local hashrate using matching time windows rather than mismatched instantaneous and averaged values.
- If the miner's firmware supports multiple pool entries, confirm that primary and backup connections are configured as intended.
Conclusion
Monitoring multiple workers under one account is largely a matter of consistent naming, correct interpretation of dashboard status categories, and recognizing that pool-side hashrate and local miner hashrate are related but separate measurements taken over different windows. Alerts reduce the need for constant manual checking, while groups, sub-accounts, Watcher URLs, and the API are optional tools that should be adopted only when they address a genuine organizational need — not as a default requirement for every mining setup.
FAQ
How quickly will a new worker appear on the dashboard?
Workers are generally detected automatically once a miner is correctly configured and begins submitting shares; exact timing can vary by coin and connection stability, so a brief delay after startup is normal before the worker appears.
Why does my miner's local hashrate differ from the pool-reported hashrate?
The two values use different measurement methods and may cover different windows. Local hashrate is reported by the device's firmware or mining software and may be a short-term average or an average since startup, depending on the field. Pool-side hashrate is estimated from the accepted work represented by shares over a rolling period, such as 10 minutes or 24 hours on ViaBTC. Check the averaging periods before comparing the readings. Short-term differences are expected and are not necessarily a sign of a problem.
What is the difference between an offline and an inactive worker?
On ViaBTC's dashboard, a worker is classified as offline if it has reported no hashrate for between 20 minutes and 1 day, and inactive if it has reported no hashrate for more than 1 day.
Should I use worker groups or sub-accounts?
Worker groups are suited to organizing and viewing multiple machines within a single account. Sub-accounts are more appropriate when separate hashrate and income reporting is needed for different sites, clients, or operational units.
Can someone monitor my workers without accessing my account?
Yes. A Watcher URL lets someone view specified account information without logging into your account or having authority to modify it. The account owner can set viewing permissions when creating the link. Share it only with intended recipients.
References
- ViaBTC Help Center, "How to Manage Workers?"
- ViaBTC, "ViaBTC Pool Hashrate and Mining Statistics Explained"
- ViaBTC Help Center, "How to Set Hashrate or Rejection Rate Notification?"
- ViaBTC Help Center, "What Is the Watcher URL?"
- ViaBTC Help Center, "What Are Sub-Accounts for? How Can I Add One?"
- ViaBTC, "How to Set Up a Worker on ViaBTC Mining Pool"
- ViaBTC Help Center, "BTC Mining"
- ViaBTC Help Center, "What Should I Do If It Shows Offline or Inactive Workers While the Miner Is Working?"
- ViaBTC Help Center, "Announcement on Hashrate Alert Feature Upgrade"
- ViaBTC Help Center, "What Is API and How to Set Up?"