You can monitor a miner from your phone by checking the mining pool account or an official pool app for worker status, submitted hashrate, shares, and alerts. Your phone does not create Proof-of-Work hashrate or replace the miner’s local management interface. It provides a remote view of pool-side data, which is useful when a miner runs continuously or is located away from you.

For a new setup, confirm that the miner is connected to the correct pool account, allow enough submitted shares for meaningful pool data, and set alerts for changes that need attention. A status indicator is a prompt to investigate, not a guarantee that the device is healthy or profitable.

What phone monitoring can and cannot tell you

Phone monitoring shows what the pool receives from your miner. Depending on the pool interface, this may include the worker name, status, reported hashrate, average hashrate, rejected shares, last-active time, and account-side earnings information.

The miner’s local interface serves a different purpose. It is where you inspect device-level details such as pool configuration, network settings, temperatures, fans, and hardware logs when supported. When you monitor a mining rig from your phone through a pool dashboard, you see its connection and submitted work—not every condition inside the machine.

A pool-side offline label can point to a network, configuration, power, or device issue, but it does not identify the cause. Use the phone to spot the signal, then use the local interface or an on-site check to investigate.

Before you check your phone: confirm the miner is connected to the correct pool account

Before diagnosing a missing worker, confirm the setup basics on the miner itself. Check that you selected the intended coin, entered the correct official pool URL, and used the correct worker or account name. Also confirm that the miner has a working network connection.

A zero-hashrate display is often a configuration or connection issue before it is a hardware failure. A typo in the account portion of a worker name can send activity to a different account. Selecting a pool endpoint for the wrong coin can prevent useful reporting. Unofficial pool URLs and software sources can also introduce connection and security risks.

Keep the account credentials used for monitoring secure. Use a strong, unique password, enable two-factor authentication when available, and review phone notification permissions so important alerts can reach you.

Step 1: Sign in to your mining pool account or official mobile app

Sign in to the same pool account configured on the miner. Start on the dashboard for the relevant coin, then look for the worker or miner-management view. A mobile miner monitoring app can make this easier when you are away from a computer, but the account and coin selection must still match the miner configuration.

Avoid relying on an old screenshot or remembered menu path. App labels and navigation can change, so use current official account and download pages and confirm that you are viewing the intended account.

Step 2: Check whether the new worker has appeared and is submitting hashrate

When you check miner hashrate on your phone for the first time, first look for the worker name. A new worker may not appear immediately because the pool needs submitted shares before it can calculate and display pool-side activity.

ViaBTC’s BTC mining guidance uses approximately 10–15 minutes as a reference point for checking operation status after a new setup. Treat that as a reference, not a universal promise for every coin, device, network, or pool.

Use this first-time sequence:

1. Confirm the miner is powered on and has network access.
2. Verify the correct coin, official pool URL, and worker or account name in the local miner interface.
3. Open the corresponding coin dashboard in the pool account or phone app.
4. Look for the new worker and check whether it is submitting hashrate.
5. If it remains absent after a reasonable reporting window, recheck configuration and connectivity.

Step 3: Read current hashrate, average hashrate, and worker status correctly

The hashrate shown on a machine can be an instantaneous or short-interval estimate. Pool-reported hashrate is calculated from submitted shares over a measurement window. Because the two measurements use different inputs and timeframes, they can differ even when the miner is operating normally.

Give a new setup time to accumulate shares before comparing figures closely. A brief dip in a pool-side estimate is not necessarily a device failure. Look for a sustained change, especially when it appears with an inactive worker, an extended last-active time, or a rising rejection rate.

An online or active worker generally indicates that the pool is receiving work. An offline or inactive worker means the pool has stopped seeing expected activity for its defined period. The status alone does not show whether the cause is a network interruption, configuration error, power event, or hardware problem.

Step 4: Check rejected shares and last-active time when something looks wrong

If the worker appears but hashrate looks weak, review rejected shares and last-active time alongside the main hashrate figure. A high rejection rate can indicate a connection-quality, latency, configuration, or other operational issue. It is different from a worker that is entirely offline.

Last-active time helps distinguish a currently communicating worker from one that stopped sending shares. If it is recent and hashrate is fluctuating, continue watching the reporting window. If it is old, move to connection and configuration checks.

Do not treat one rejected share or a brief hashrate variation as proof that the machine is failing. Look for a persistent pattern and compare it with the miner’s local logs and network condition.

Step 5: Set Hashrate Alert, offline-worker, or rejection-rate alerts on your phone

Alerts reduce the time between a meaningful change and your first check. A Hashrate Alert can help you notice a sustained decline, an offline-worker alert can tell you when pool-side activity stops, and a rejection-rate alert can flag a different type of problem.

Set thresholds that reflect the normal range of your own device rather than reacting to every short fluctuation. Alerts should prompt a review, not an automatic conclusion that the hardware has failed.

ViaBTC supports notifications for hashrate and rejection-rate events through available channels such as email, app push, or Telegram. Confirm the current channels and setup path in your account before relying on them. Make sure your phone permits notifications from the official app and test that an enabled alert can reach you.

What to do if the miner shows offline or zero hashrate

Use a fixed troubleshooting order when a phone dashboard shows zero hashrate or an offline worker:

1. Check whether the status change is recent and whether the pool may still be updating its measurement window.
2. Confirm power and internet connectivity at the miner’s location.
3. Review the configured coin, official pool URL, and worker or account name in the local interface.
4. Check whether the worker is reporting under a different account or coin dashboard.
5. Review last-active time, rejected shares, and local logs for a more specific clue.
6. Move to device-level or on-site checks if the configuration and connection are correct but the worker remains inactive.

A remote dashboard can identify missing pool-side communication, but it cannot restore power, repair a cable, or confirm a hardware fault. Avoid changing several settings at once; make one verified correction, then allow time for new shares to reach the pool.

A simple daily phone-monitoring checklist for new miners

A short daily review is usually more useful than repeatedly refreshing a single number.

• Confirm that the expected worker is active in the correct coin dashboard.
• Compare pool-side hashrate with its recent normal range, not only with an instantaneous machine reading.
• Review last-active time when activity appears to stop.
• Check whether rejection rate has changed materially.
• Review new alerts and verify that phone notifications remain enabled.
• Investigate sustained changes with the miner’s local interface or an on-site check.

Displayed earnings and daily estimates should remain separate from this operational checklist. They do not guarantee future profitability or uninterrupted operation.

Using ViaBTC Pool App to view mining status and alerts

The ViaBTC app download page is the appropriate starting point for obtaining the official mobile app. The app supports real-time hashrate monitoring, miner-status viewing, miner group management, alerts, and monitoring across multiple pools or accounts. Confirm current availability and interface labels before following a specific navigation path.

Use the app as a convenient pool-side monitor. For local device settings, hardware telemetry, or physical troubleshooting, return to the miner’s own management interface and operating environment.

FAQ: How long should a new miner take to appear on my phone?

When should a worker appear?

A worker appears after the pool receives enough submitted shares to report activity. ViaBTC’s BTC mining guidance suggests checking status after approximately 10–15 minutes following setup. Actual timing can vary by coin, miner, network conditions, and pool measurement method. If the worker does not appear, verify the coin, official pool URL, worker or account name, and internet connection.

Why do phone and miner hashrate differ?

The miner may show an instantaneous estimate, while the phone dashboard usually shows pool-side hashrate derived from submitted shares over a measurement window. Short-term differences are expected. Compare trends over time and investigate when a difference persists or appears with an inactive worker or other warning signal.

What should I do after an offline alert?

First confirm when the worker was last active and whether the pool dashboard has had time to update. Then check power, network connectivity, the configured coin, the official pool URL, and the worker or account name. Review the local miner interface before treating the alert as a confirmed hardware failure.