Monitoreo de minería y alertas: cómo enterarte de un downtime en minutos, no en un día

El downtime en una granja casi nunca es dramático. No se apagan las luces, no sale humo. Simplemente, en algún momento, parte de las máquinas deja de entregar shares, y te enteras por la mañana, cuando el pago resulta menor que el de ayer. Para entonces el dinero ya se perdió, y no se puede recuperar: la red no recalcula tu parte retroactivamente.

A continuación analizamos por qué el dashboard del pool no sirve bien como sistema de alertas, qué métricas avisan de una falla con anticipación y cómo armar una alerta simple con lo que ya tienes a mano.

Cuánto cuesta una hora de downtime

Calculamos con la fórmula que usa cualquier calculadora de rentabilidad:

\`\`\`

BTC por día = (hashrate × 86400) / (dificultad × 2^32) × 3.125

\`\`\`

Aquí 86400 son los segundos del día, 2^32 sale de la definición de la dificultad, y 3.125 BTC es el subsidio actual por bloque (valor de nuestro corte de red del 08.09.2026).

Sustituyendo una dificultad de 127,45 billones (mempool.space, 08.09.2026) y un tipo de cambio de 78.349 dólares:

El cálculo es bruto, antes de la comisión del pool y de la electricidad, y no incluye las comisiones de transacción (según mempool.space, al 08.09.2026 añadían un 0,66% a la recompensa en una ventana de 4320 bloques, es decir que en orden de magnitud casi no cambia nada).

Después viene la aritmética simple. Un fallo a la una de la madrugada, notado a la una de la tarde. Doce horas, granja de 10 PH/s: unos 193 dólares que simplemente no aparecerán en el pago. Si esto coincide una vez al mes, en un año te cuesta más de dos mil dólares con equipo perfectamente funcional.

Por qué el dashboard del pool no reemplaza el monitoreo

En resumen: el pool no muestra el estado de tu equipo, sino el estado del flujo de shares que llegó hasta el pool. Entre el corte y el cambio de estado en el dashboard pasan decenas de minutos, porque el pool debe distinguir una falla real de un corte de conexión común. En AntPool esto está formalizado oficialmente: un worker recibe el estado Inactive después de 20 minutos sin shares, y el estado Invalid solo tras 24 horas de silencio (AntPool support, Worker Management).

Veinte minutos ya son 5,4 dólares con 10 PH/s, y ese es el mejor de los casos: el worker se cayó por completo y el estado efectivamente cambia. Si la máquina funciona pero entrega la mitad, el estado seguirá en verde, y el pool no te dirá nada.

Hay una segunda razón. El hashrate en el dashboard del pool no es una medición, sino una estimación basada en la cantidad de shares aceptados en una ventana de promedio. Cada pool tiene su propia ventana, y no siempre se indica en la documentación. Cuanto más corta la ventana, más nervioso el gráfico; cuanto más larga, más tarde reacciona ante una caída real.

Los valores de retraso y umbrales en otros pools verifícalos en su propia documentación: cifras confirmadas oficialmente solo encontramos en AntPool, y no se pueden trasladar a otros pools.

Tres niveles de observación

Se puede observar en tres lugares, y cada uno ve su parte del panorama.

Ningún nivel es autosuficiente. El minero avisará honestamente de un sobrecalentamiento, pero callará si tu proveedor cortó la ruta hacia el pool. El pool verá la caída de shares, pero con retraso y sin explicar la causa. El sensor de energía reaccionará al instante, pero no distinguirá una máquina apagada de una colgada.

El mínimo funcional es el primer y el tercer nivel: datos locales para la causa, datos del pool para confirmar que el trabajo realmente se pagó.

Qué métricas avisan de una falla con anticipación

Respuesta directa: la proporción de shares rechazados, una divergencia sostenida entre el hashrate local y el del pool, la temperatura de los chips y el contador de reinicios. Estas cuatro cifras cambian antes de que la máquina se detenga por completo, y dan tiempo para intervenir antes de que el downtime sea total.

1. Shares rechazados (reject rate). Un aumento en la proporción de rechazos casi siempre es la red: pérdida de paquetes, router saturado, ruta defectuosa hacia el servidor del pool. No busques la norma de rechazos en artículos de otros, sino en tus propios datos durante una semana tranquila: cada combinación de equipo y proveedor tiene la suya.
2. La brecha entre el hashrate local y el del pool. Más abajo hay una sección aparte sobre esto, porque aquí es donde más se cunde el pánico sin razón.
3. Temperatura de los chips y revoluciones de ventiladores. Un radiador cubierto de polvo sube la temperatura gradualmente. La máquina primero reduce la frecuencia por sí sola, perdiendo rentabilidad en silencio, y recién después entra en protección. Es precisamente esta fase de degradación silenciosa la que se detecta bien con un umbral de temperatura.
4. Contador de uptime. Si el uptime de la máquina se reinicia con regularidad, tienes reinicios de los que el pool no te avisará: entre reinicios los shares fluyen, el estado está en verde, pero la producción total es menor.
5. Número de hashboards funcionando. Una placa caída en una máquina de tres placas es un tercio menos de ingreso con el worker completamente vivo en el dashboard.

Por qué el pool siempre muestra menos que el propio minero

Respuesta directa: el minero muestra la velocidad de búsqueda que él mismo calculó, y el pool muestra una estimación reconstruida a partir de los shares aceptados. La segunda magnitud es estadística, por eso oscila y en promedio resulta menor: parte del trabajo se va en shares rechazados y retrasados, parte se pierde en el redondeo de la ventana de promedio.

La regla práctica es simple. Una divergencia de unos pocos puntos porcentuales que sube y baja a lo largo del día es una dispersión normal de la muestra, no una falla. La señal real se ve distinta: el hashrate del pool baja y se queda ahí, mientras que el local no cambia. Ese cuadro significa que la máquina calcula, pero el resultado no llega al pool o no se contabiliza.

Cuál es la norma para tu combinación concreta, nadie te lo puede decir por ti. Reúne tus propias cifras durante una semana tranquila, calcula la proporción promedio entre el hashrate del pool y el local, y parte de ahí. Lo mismo vale para todos los umbrales de abajo.

Cómo armar una alerta sin servicios de terceros

Hace falta cualquier máquina que funcione las 24 horas y sepa hacer peticiones HTTP: un mini servidor casero, un router con capacidad de ejecutar scripts, una laptop vieja. Luego, dos fuentes de datos.

Del lado del minero. La interfaz web del ASIC entrega el hashrate actual, temperaturas, revoluciones, uptime, estado de los hashboards y contadores de rechazo. En muchos firmwares los mismos datos están disponibles en formato legible por máquina a través de una API local o un socket de gestión. Las direcciones y formato exactos dependen del fabricante y la versión del firmware; consulta la documentación de tu modelo.

Del lado del pool. Algunos pools tienen una API de cuenta con el hashrate de los workers y sus estados, mediante una clave del panel personal. La disponibilidad, formato y límites de peticiones varían de pool a pool, y hay que verificarlo en la documentación de cada uno: no hay un estándar único aquí, y no hemos confirmado endpoints más allá de lo descrito en nuestros informes.

La lógica del script cabe en una decena de líneas: consultar los mineros cada minuto, consultar el pool cada varios minutos, comparar los valores con los umbrales, y al detectar una infracción enviar un mensaje a un mensajero o correo. Prevé también el caso inverso: si el propio script deja de responder más de media hora, significa que se cayó él, no la granja. Un monitor silencioso es el peor tipo de monitor, porque crea una falsa sensación de control.

Qué umbral poner para no ahogarte en falsas alarmas

Respuesta directa: no por una sola medición, sino por varias seguidas. La búsqueda de shares es un proceso aleatorio, y las caídas breves del gráfico son inevitables incluso en una granja en perfecto estado. El umbral debe exigir que la desviación se mantenga durante varios intervalos de consulta seguidos, de lo contrario recibirás alertas cada hora y muy pronto dejarás de leerlas.

Un esquema práctico se ve así:

1. Silencio total del minero. La consulta local no responde dos veces seguidas. Esto ya no es dispersión, hay que reaccionar de inmediato.
2. Caída del hashrate. Valor por debajo de tu norma habitual y sostenido durante varias mediciones seguidas. Cuánto por debajo y cuántas mediciones, defínelo según tu propio historial de una semana tranquila.
3. Temperatura. Toma el umbral de la documentación del fabricante de tu modelo, y pon la alerta con margen por debajo de la temperatura de disparo de la protección, para tener tiempo de reaccionar antes de un apagado de emergencia.
4. Shares rechazados. Compara con tu propio fondo habitual, no con una cifra absoluta sacada de internet.
5. Silencio del pool. Útil, pero recuerda el retraso: en AntPool incluso el estado oficial Inactive aparece recién a los 20 minutos. Esta alerta siempre llegará más tarde que la local.

Otra regla: cada alerta debe tener un tiempo de espera después de dispararse. De lo contrario, una falla a las tres de la madrugada se convertirá en cuarenta mensajes idénticos, y por la mañana estarás lidiando con notificaciones en vez de con la granja.

Decide aparte qué hacer en el momento en que se dispara la alerta. Si la granja no está en tu casa, una alerta sin posibilidad de actuar a distancia se convierte en una forma de arruinarte la noche. Aquí se conecta el tema del pool de respaldo: parte de las fallas no son averías de hardware, sino problemas del lado del pool o de la ruta hacia él, y se resuelven con un cambio automático, no con un viaje. Sobre cómo configurar una dirección de respaldo escribimos aparte.

Checklist para una tarde

1. Calcula tu propio costo de una hora de downtime con la fórmula de arriba. Un solo número le da sentido a todo el trabajo posterior.
2. Reúne una línea base: hashrate local, hashrate del pool, temperaturas, proporción de rechazos durante un día tranquilo.
3. Comprueba si tu firmware entrega datos de forma legible por máquina, y anota la dirección.
4. Verifica en la documentación de tu pool si hay una API de cuenta y qué limitaciones tiene.
5. Escribe una consulta a los mineros cada minuto, con registro en un archivo o una base de datos simple.
6. Configura cuatro alertas: sin respuesta, caída de hashrate, temperatura, aumento de rechazos.
7. Añade un tiempo de espera tras cada disparo y una protección contra un monitor silencioso.
8. Verifica todo honestamente: desconecta el cable de red de una máquina y mide cuánto tarda en llegar el mensaje.
9. Configura un segundo pool en los ajustes del minero, si aún no lo has hecho.
10. Después de una semana, revisa los umbrales con los datos acumulados. Casi nunca aciertan a la primera.

El punto ocho es el que más se salta, y es el único que demuestra que el sistema realmente funciona.

Qué leer a continuación

• Calculadora de rentabilidad de minería: introduce tu propio hashrate y mira cuánto cuesta un día de downtime en tu caso concreto.
• El pool está caído: cómo saber que el problema no es tu granja: cómo distinguir un problema de tu lado de uno del lado del pool.
• Pool de respaldo: por qué configurar una segunda dirección: cambio automático ante una falla sin que tengas que intervenir.
• Comparación de pools de minería: comisiones, esquemas de pago y umbrales de retiro.

El monitoreo no aumenta el ingreso. Solo evita perder lo que ya se ganó, y en la minería la diferencia entre estas dos cosas es prácticamente nula.