Monitoring
Monitoring is automatic watching over your asics plus alerts when something has stopped. Without it downtime is measured in the hours before you happen to look.
What mining monitoring is
The data comes from two sides. The pool knows whether a worker is sending shares and can write to you when it goes quiet. The asic itself gives out more over the network: temperatures, fan speeds, the count of live hashboards, errors. The first takes five minutes to set up, while the second gives you a diagnosis.
A monitoring service gets by with a read only key. Rights to make changes are needed only by whoever will reboot asics and alter settings, and rights like that are handed out separately and on purpose.
The main mistake is noise in the alerts. If an alert arrives on every wobble in hashrate, a week later you stop reading them, and real downtime slips past. There should be few thresholds, and each one should mean an action.
The second missing piece is history. An instant figure does not answer the question of what happened overnight; a chart for the week does. Without history every breakdown looks sudden.
Quick reference table
| What the pool gives | a silent worker, accepted and rejected shares |
| What the asic itself gives | temperatures, fans, live boards, errors |
| What rights are needed | a read only key |
| The main mistake | too many alerts |
| Useless without history | instant figures |
What to set alerts on
A worker silent for longer than fifteen minutes. This is the most valuable alert of the lot: it catches the network, the power and the death of an asic.
Temperature above your working band. The threshold gets set from your own experience rather than from the spec sheet: what matters is the figure usual for this rack rather than an absolute degree.
The count of live hashboards has dropped. The asic keeps running and keeps paying, so without an alert a partial zombie can easily go unnoticed for a month.
The proportion of rejected and late shares has grown several times over. This is about the network and about stability, and it is cheaper to catch straight away.
Do not set an alert on daily revenue. It wanders with the price of hash rather than with your hardware, and alerts like that only train you to ignore your phone.
An example of a setup
Ten asics run on three rules: a worker silent for a quarter of an hour, temperature above the working band, the count of live hashboards dropped. Two or three alerts arrive in a month, and each one means a walk to the rack. Messages like that get read, while a list of thirty rules gets read by nobody.
Related terms
Where to go next on the site
Software
- Software firmware
- HashCore Toolkit firmware
Hardware
- ASIC Miner knowledge base
Questions and answers
Are alerts from the pool enough
On one or two asics, yes. Beyond that you need temperatures and the count of live boards, and the pool does not see those.
What rights should you give a service
Read only. A key that can alter settings is needed just for a remote reboot, and it gets issued separately.
What do you do if there are too many alerts
Cut the rules down to the ones that really send you to the rack. An alert with no action behind it is rubbish.
How the terms connect
Every link in the chain is clickable. Orange marks where you are now.
Looking for an ASIC miner
The catalog holds 212 models. You can compare them by hashrate and by joules per terahash, then plug your own rate into the calculator and see what stays in your pocket.
Page written and checked by Denys Klimchuk. Updated .