A mining alert is useful because it shortens the time between an operating problem and a response. It does not repair an ASIC, identify the root cause automatically, or guarantee a particular amount of BTC revenue.
ViaBTC supports Telegram notifications for mining operations, including worker-offline and rejection-rate alerts. Hashrate and rejection-rate thresholds can also be configured from the pool dashboard, with Telegram available as a notification method.
The most effective setup combines the alert itself with clear thresholds, an assigned responder, and a repeatable troubleshooting process.
What Telegram Alerts Can and Cannot Tell You
An alert indicates that a configured condition has been met.
It does not automatically identify the cause.
A worker may go offline because of:
- an ASIC reboot;
- a power interruption;
- a failed power supply;
- an Ethernet or switch problem;
- an ISP outage;
- planned maintenance; or
- an incorrect mining configuration.
A rejection-rate alert means something different. The worker can remain online while network delay, high temperature, firmware instability, or tuning settings increase the number of rejected shares.
Hashrate alerts also require context. A miner's local hashrate and the pool's hashrate estimate can use different averaging windows. ViaBTC's real-time pool hashrate is calculated from the previous 10 minutes, while a miner interface may refresh far more frequently.
The operating principle is simple: an alert starts an investigation; it does not finish one.
Connect ViaBTC Notifications to Telegram
ViaBTC uses the official Telegram bot @ViaBTC_Official_Bot.
On the web
- Sign in to ViaBTC and open Account Management → Notifications.
- Open @ViaBTC_Official_Bot from the page.
- Select Start or send /Chat ID to obtain the Chat ID.
- Return to ViaBTC, enter the Chat ID, and save it.
A mining account can bind one Chat ID, while different mining accounts can bind the same Chat ID.
For a Telegram group
- Add @ViaBTC_Official_Bot to the group.
- Send /Chat ID in the group.
- Copy the returned group Chat ID, including the leading minus sign.
- Save that Chat ID in ViaBTC.
All group members can then receive notifications sent to the group.
ViaBTC's current setup guide is available here: How to Set Telegram Alert?
Configure Alerts From the Pool Dashboard
ViaBTC allows miners to configure hashrate or rejection-rate notifications from:
Pool → Dashboard → Alert Settings
After setting the relevant parameters, choose Telegram under the notification method.
ViaBTC also supports worker-offline and rejection-rate notifications through Telegram.
See: How to Set Hashrate or Rejection Rate Notification?
Start With Worker-Offline Alerts
Worker-offline alerts are a practical first layer because they identify miners that are no longer contributing normally from the pool's perspective.
The first response should depend on the scope.
One worker offline
- check the miner interface;
- review power-supply status;
- check Ethernet link and switch port;
- confirm whether a reboot or maintenance task was expected.
Several workers in one rack or container offline
- check rack power;
- review the switch or uplink;
- check local environmental alarms;
- look for a common network or power event.
A broad site-wide decline
- review upstream connectivity;
- facility power;
- DNS or routing;
- planned curtailment;
- pool configuration.
The objective is to identify the common failure domain before replacing individual hardware.
Add Rejection-Rate Alerts
Rejected shares are submitted shares that the pool does not credit.
Where the pool exposes rejection reasons, stale, invalid, duplicate, and other reasons should be treated as subcategories of rejected shares rather than unrelated peer metrics.
ViaBTC identifies network delay, high equipment temperature, and firmware issues as possible causes of a high rejection rate. Its support guidance describes a rejection rate within 3% as normal.
That 3% figure should be treated as ViaBTC-specific practical guidance, not a universal benchmark for every ASIC, coin, network path, or mining pool.
More important than a single number is whether the rejection rate changes materially from the account's normal baseline.
See: What if the Rejection Rate Is High?
Set Hashrate Thresholds From the Account's Own Baseline
A useful threshold should reflect the normal operating range of the account.
Review pool-side statistics over comparable operating periods and account for:
- planned maintenance;
- curtailment;
- commissioning;
- miners being added or removed;
- firmware changes;
- seasonal thermal conditions.
Avoid copying a threshold from another operation without context.
A threshold that is too sensitive can create repeated false alarms. A threshold that is too loose can allow a meaningful decline to continue unnoticed.
Review alert settings after material changes to fleet size, power policy, firmware, cooling, or site configuration.
Use a Defined Triage Process
A short triage table can keep responses consistent.
| Alert pattern | First checks | Typical next step |
|---|---|---|
| One worker offline | Miner interface, PSU, Ethernet link, switch port, recent reboot | Restore under site procedure or escalate if it does not recover |
| Several workers in one rack or container offline | Rack power, switch, uplink, cooling or local alarms | Treat as a shared infrastructure event until ruled out |
| Site-wide decline | Upstream connectivity, facility power, routing, curtailment, pool configuration | Confirm scope and follow the site escalation path |
| Rejection rate rises while workers remain online | Network quality, temperatures, firmware logs, tuning settings | Identify the rejection reason before changing the pool |
| Pool-side hashrate below local display | Compare matching windows, then review rejections and connectivity | Investigate only after the time-window comparison is aligned |
For team operations, it is useful to define who acknowledges an alert, who performs the first technical check, and when an incident should be escalated.
The exact team structure depends on the size and operating model of the site.
Treat Backup Connections as a Separate Control
Telegram alerts notify people that something may require attention. Backup connection settings help miners continue working when a configured connection becomes unavailable.
ViaBTC recommends configuring multiple ports for BTC mining so that a miner can move to the next configured connection if one fails.
Verify backup configuration during normal operations:
- confirm the URL and port;
- confirm worker credentials;
- check that the miner can reconnect;
- review pool-side hashrate after the switch.
Do not wait for an unexpected connectivity problem to discover that the fallback configuration was never tested.
See: BTC Mining
Measure Whether Alerts Improve Operations
The most useful alert-performance records are operational timestamps.
Track:
- event or alert time;
- acknowledgement time;
- diagnosis time;
- restoration time.
These records show whether notifications are reaching someone who can act and whether repeated faults are being corrected.
After an incident, compare:
- worker status;
- reconnect logs;
- rejected shares;
- pool-side hashrate;
- local miner logs; and
- credited mining rewards.
Keep BTC-denominated mining results separate from USD valuation. BTC price changes the fiat value of earnings, while an operational incident affects mining output through lost operating time or degraded share submission.
Build Alerts Into a Routine
Telegram alerts are most useful when they are tested and reviewed.
Periodically confirm that:
- the Telegram Chat ID is still bound correctly;
- the alert group has the right participants;
- thresholds still match the current fleet;
- maintenance and curtailment periods are documented;
- backup ports or endpoints still work;
- repeated incidents are reviewed for common causes.
A recurring fault from the same switch, power circuit, firmware version, or cooling zone is more useful than an isolated alert because it points to a pattern the operation can address.
Conclusion
Telegram hashrate alerts do not prevent mining problems on their own. They help reduce detection time and give miners a faster path from an anomaly to investigation.
The most effective setup combines sensible thresholds, worker-offline and rejection-rate alerts, tested backup connections, and a clear response process.
Used this way, Telegram becomes an operations tool for reducing avoidable downtime rather than just another notification channel.
FAQ
Do Telegram alerts prove an ASIC has failed?
No. They indicate that a configured pool-side condition has been met. Confirm the cause using miner-side information, network checks, and maintenance records.
Should every hashrate decline trigger an alert?
No. Thresholds should reflect the account's own operating baseline and planned maintenance or curtailment schedule.
Is a rejection-rate alert the same as a worker-offline alert?
No. A worker can remain online while submitted shares are rejected at a higher rate.
Can a Telegram group monitor more than one ViaBTC mining account?
Yes. Different mining accounts can bind the same Telegram Chat ID.
What is the main benefit of Telegram alerts?
They can shorten the time between a pool-side anomaly and a human response, which can help limit avoidable downtime.