Setting Up Mobile Alerts for Hashrate Drops
A hashrate drop costs nothing until you notice it, and the arithmetic is unforgiving: at current difficulty a 100 TH/s machine earns about $3.80 a day, or $0.16 an hour, so a failed fan that goes unnoticed for half a day quietly removes nearly a dollar from a single machine. Mobile alerts exist to shrink that blind window from days to minutes, and they work best when they are built on the same numbers the pool uses to pay you.
Key takeaways
- At difficulty 132.76 T, 100 TH/s produces 0.0000449 BTC a day — about $3.80, or $0.16 per hour of uptime lost.
- The same 24-hour failure costs a 1 PH/s operation about $37.99, which is the entire day's gross, so alert latency scales with farm size.
- Alert on per-worker hashrate, not on totals: an aggregate view can hide one dead machine behind eleven healthy ones.
- Settlement cadence is the backstop: hourly PPS+ credits of about 0.0000187 BTC per PH/s make a missing hour visible without opening a dashboard.
The short answer
Set two alerts per machine: a floor alert that fires when a worker's hashrate falls more than about 15% below its own seven-day baseline, and a silence alert that fires when no shares are submitted for 20 minutes. Run both on push notifications rather than email, because email arrives when you next check email, and keep a weekly reconciliation of credits against worker uptime for the cases neither alert catches.
How the mechanism works
Pool payouts are computed from shares the pool actually received, not from what a miner believes it submitted. That is why the per-worker hashrate figure is the useful signal: the pool derives it from share timestamps, so it reflects the work that earned money. When hashrate for one worker falls, either the machine stopped hashing, the connection between the miner and the pool degraded, or the target it was assigned no longer matches what it can compute.
What you are really measuring
Three distinct numbers get collapsed into the word "hashrate" on most dashboards. Nominal hashrate is what the firmware advertises. Effective hashrate is what the pool credits you with over a window, after rejects and stale shares. Settled income is the currency amount those shares converted into. Only the second one is comparable across pools, and only the third one pays an electricity bill.
Why hourly settlement makes alerts cheaper to build
When settlement is hourly, every hour is also a heartbeat. A 1 PH/s miner expects about 0.0000187 BTC per hour, so an hour that arrives short is evidence of lost uptime somewhere, and two short hours in a row is a pattern worth investigating. With monthly settlement that same signal is buried inside a single payment and cannot be used for triage at all.
| Time until noticed | Lost output at 100 TH/s | Lost output at 1 PH/s |
|---|---|---|
| 1 hour | About $0.16 | About $1.58 |
| 6 hours | About $0.95 | About $9.50 |
| 12 hours | About $1.90 | About $19.00 |
| 24 hours | About $3.80 | About $37.99 |
Where miners get it wrong
Alerting on totals instead of workers
A farm-wide threshold misses the failure that matters most: one machine down out of twelve changes the total by about 8%, which most operators set as a tolerance. Per-worker floors catch it immediately, because the comparison is a machine against its own history rather than against the farm.
Ignoring legitimate variation
Difficulty retargets, share difficulty changes and temperature swings all move reported hashrate without anything being wrong. The next adjustment was estimated near -2.12% on the read date, which is a normal oscillation, not a fault. Alerts that fire during routine variation get muted, and a muted alert is worse than no alert because you believe you are covered.
Forgetting the money path
Hashrate can look perfect while income drops, if the fee component or payment method changed, or if a worker is submitting to a lower-paying chain than intended. Keep a monthly reconciliation of settled credits against expected output, and query the pool's own network statistics page when the arithmetic does not match, since network difficulty and pool hashrate both shift the expected value.
A worked example
Consider one 100 TH/s machine on a farm where electricity costs $0.06/kWh and the machine runs at 20 J/TH, so it draws about 2 kW and consumes 48 kWh a day, or $2.88 of power. Gross output at current difficulty is 0.0000449 BTC, which is $3.80 at $84,692 — a margin of $0.92 per day at that power price, before the listed 4% fee on the block-reward component.
Now suppose a fan controller fails at 22:00 and nobody notices until the next morning. Twelve hours of downtime costs $1.90 of gross output while the power draw falls only partly, so a single night erases roughly two days of that machine's net margin. An alert that fires within 20 minutes turns the same incident into a $0.05 event.
Alerts are only useful if they arrive where you already are. A miner who wants worker-level push notifications, hashrate history and the balance in the same authenticated view can consolidate all three in one client: the official ViaBTC App Download supports real-time hashrate monitoring and alerts on both iOS and Android, with multi-account management for operators who run more than one mining pool account.
A checklist you can run today
- Record a baseline. For each worker, note the median effective hashrate over the last seven days.
- Set a floor at 85% of baseline and a silence alert at 20 minutes without shares.
- Test both alerts by unplugging one machine's network cable for ten minutes, then confirm the notification arrived and the worker recovered.
- Check notification routing. Push to a phone you carry, and add a second recipient if more than one person runs the site.
- Reconcile weekly. Compare settled credits with expected output using the pool's mobile mining dashboard and network difficulty for the same period.
- Review thresholds after every retarget so normal difficulty movement does not trigger them.
Frequently asked questions
Does the payout method change my average income?
It changes the variance and the fee, not the underlying expected value: your share of network hashrate still sets the ceiling.
How often should a miner check pool statistics?
Weekly is enough for cash flow, daily if you are reconciling worker uptime or chasing a hashrate fault.
How do I tell a hardware fault from a pool-side problem?
Look at the workers individually. If one machine is short while its neighbours are normal, the fault is local to that machine. If every worker drops in the same minute, check the site uplink and the pool's status before touching hardware.
What is a sensible alert threshold?
A floor around 15% below a worker's own seven-day median catches dead fans and failing power supplies while leaving room for normal share variance. Anything tighter will fire during routine difficulty movement.
Tune the alerts before the next failure
Pick one machine, record its seven-day baseline, and create the two alerts described above. Verify that both actually reach your phone, then roll the same thresholds out to the rest of the farm. If it helps, keep a single page of numbers — baseline hashrate, expected daily BTC and settled credits — because the moment a drop becomes ambiguous, that page tells you whether you are looking at a hardware problem or an accounting one.
Data and sources: ViaBTC pricing page for the listed PPS+ fee structure[1] and the ViaBTC mining statistics page for pool and network hashrate[2]. Network difficulty (132.76 T), network hashrate (about 1,003 EH/s), the 3.125 BTC block subsidy, the estimated -2.12% next adjustment and the BTC price of $84,692 were read from public chain data and market feeds on 21 September 2026. Figures are illustrative and move with difficulty and price.