El modo de fallo del que nadie habla: una tarea programada deja de ejecutarse y nada te lo comunica. Windows Task Scheduler muestra un estado verde “Listo” mientras el script subyacente sale silenciosamente por una dependencia faltante durante tres semanas. Un trabajo cron en el servidor del hogar sobrevive a una actualización de SO en el cronograma pero no en el entorno, y la copia de seguridad que debería ejecutarse cada noche deja de escribir archivos. El sistema no cree que haya algo mal porque nada fue lanzado. La copia de seguridad simplemente desapareció.
Probamos 7 mejores aplicaciones para detectar fallos silenciosos de tareas programadas en Linux, Windows y macOS en 2026. La lista cubre los servicios dead-man-switch que esperan un ping de tu trabajo y alertan cuando se silencia, los monitores de tiempo de actividad generales que también manejan heartbeats en modo push, los exportadores de métricas que permiten graficar el patrón, y las herramientas locales que convierten la señal bruta en una alerta donde realmente la lees.
Qué buscar en un monitor de tareas programadas
Elige una herramienta que:
- Utilice un dead-man switch, no solo “comprueba si el código de salida fue cero.” El punto es que el trabajo no se está ejecutando en absoluto.
- Maneje la tolerancia de cronograma sensatamente. Un trabajo que se ejecuta a las 03:00 debería tolerar algunos minutos de desvío antes de alertar; un trabajo que se ejecuta cada minuto no debería tolerar horas.
- Envíe alertas a un canal que verificas. El correo electrónico está bien hasta que el apagón está en tu servidor de correo; superpón al menos un canal que no sea correo electrónico (un servicio push, un webhook de Discord, un SMS).
- Se ejecute independientemente del host que monitorea. Un monitor que muere con la caja que vigila no es un monitor.
- No requiera pago por trabajo. Los hogares a menudo tienen veinte o treinta tareas programadas; un modelo de facturación por trabajo convierte la infraestructura del hogar en un centro de costos corporativo.
Comparación rápida
| Aplicación | Mejor para | Enfoque | Auto-alojada | Nivel gratuito |
|---|---|---|---|---|
| Healthchecks.io | Dead-man switch con opción auto-alojada | Push heartbeat | Sí | Sí, 20 comprobaciones |
| Cronitor | Telemetría completa de cron con estadísticas por trabajo | Push + wrapper | No | Sí, 5 monitores |
| Dead Man’s Snitch | El servicio de heartbeat original para tareas programadas | Push heartbeat | No | Sí, 1 snitch |
| Uptime Kuma | Monitor de tiempo de actividad auto-alojado con modo push | Pull + push | Sí | Gratis, auto-alojada |
| Prometheus Node Exporter | Métricas para estado de systemd timer | Pull métricas | Sí | Gratis |
| systemd | Detección nativa de fallos en Linux | Nativa | Sí | Gratis |
| Gotify | Servidor de notificación push auto-alojado | Push server | Sí | Gratis |
Por qué “la tarea se ejecutó” no es lo mismo que “la tarea funcionó”
El modelo mental que usa la mayoría de programadores es “¿terminó el proceso?” y el modelo mental necesario es “¿ocurrió el resultado?” Un script de copia de seguridad que terminó exitosamente porque el directorio de origen estaba vacío no es una copia de seguridad que funcione. Una sincronización que terminó exitosamente porque la red estaba desconectada y el bucle de reintentos se detuvo silenciosamente no es una sincronización que funcione. Una tarea de rebuild-search-index que terminó exitosamente porque el demonio estaba inactivo y el cliente devolvió una respuesta vacía no es una reconstrucción que funcione.
La solución es de dos capas: el trabajo envía un heartbeat solo después de completar su trabajo real (no solo después de iniciarse), y el monitor alerta cuando falta el heartbeat. Nada más en la pila de cronograma detecta el modo “silenciosamente no hacer nada”. Task Scheduler no lo hará. Cron no lo hará. Windows Event Log no lo hará.
Las aplicaciones
1. Healthchecks.io — mejor dead-man switch con opción auto-alojada
Healthchecks.io es la implementación de referencia del patrón dead-man-switch. Cada tarea programada obtiene una URL única, la tarea hace curl a esa URL al final de su ejecución exitosa, y Healthchecks alerta si el ping no llega en la ventana esperada. Períodos de gracia por comprobación, ping-with-exit-code (así que curl $URL/fail marca explícitamente la comprobación como fallida), y cronogramas por comprobación expresados como un intervalo simple o una expresión cron completa. Slack, Discord, PagerDuty, Gotify, ntfy, correo electrónico, SMS, webhook, y aproximadamente veinte otros canales de alerta.
Dónde falla: El nivel gratuito alojado se limita a 20 comprobaciones; los hogares con grandes superficies de automatización lo superarán. El auto-alojamiento lo soluciona pero agrega un servicio para mantener.
Plataformas: Cualquier host Linux/Docker para auto-alojamiento. El nivel alojado funciona desde cualquier cosa que pueda hacer una solicitud HTTP.
Descargar: Healthchecks.io install
Conclusión: La opción por defecto correcta para heartbeats de tareas programadas en un servidor del hogar.
2. Cronitor — mejor telemetría completa de cron con estadísticas por trabajo
Cronitor va más allá del heartbeat y captura la imagen de tiempo de ejecución completa — cuánto tiempo tardó el trabajo, código de salida, stdout y stderr, gráficos comparativos entre ejecuciones, y alertas en cualquiera de estos cambios. Envuelve el trabajo en la CLI de Cronitor o hace ping a la URL directamente al inicio, fin y fallo. El panel está dirigido a equipos; un hogar que use la mitad de las funciones seguirá obteniendo valor solo de los gráficos de tiempo de ejecución.
Dónde falla: Solo alojado — sin opción de auto-alojamiento. El nivel gratuito es de 5 monitores, que se llena rápidamente en un servidor ocupado.
Plataformas: Cualquier host que pueda hacer HTTPS saliente. CLI wrapper para Linux, macOS, Windows.
Descargar: Cronitor download
Conclusión: La opción correcta cuando deseas gráficos de tiempo de ejecución por trabajo y estás cómodo con un servicio alojado.
3. Dead Man’s Snitch — mejor el servicio de heartbeat original
Dead Man’s Snitch popularizó el patrón y sigue siendo una de las formas más fáciles de detectar un fallo silencioso. Crea un snitch, obtén una URL, haz que el trabajo golpee esa URL, obtén un correo electrónico si la URL no es piteada dentro del intervalo. Ese es el producto completo. Cuando “¿hay algo que deba ser más complicado que esto?” es la pregunta correcta, Dead Man’s Snitch es la respuesta honesta.
Dónde falla: El nivel gratuito es un snitch — eso es suficiente para proteger un trabajo crítico y nada más. La profundidad de características se queda atrás de Healthchecks y Cronitor.
Plataformas: Cualquier host que pueda hacer HTTPS saliente.
Descargar: Dead Man’s Snitch signup
Conclusión: La opción correcta cuando la alerta “la copia de seguridad no se ejecutó” es el único resultado que necesitas proteger.
4. Uptime Kuma — mejor monitor de tiempo de actividad auto-alojado con modo push
Uptime Kuma es el monitor de tiempo de actividad auto-alojado que creció con un modo push adecuado junto con sus sondeos HTTP y TCP. Interfaz point-and-click, la mayoría de canales de alerta que la gente necesita, páginas de estado por comprobación, y el mismo modelo “comprobación enviada en X segundos” que Healthchecks. Si el servidor del hogar ya ejecuta Uptime Kuma para la pila de medios, agregar heartbeats de trabajos cron al mismo panel cuesta algunos clics.
Dónde falla: El soporte en modo push es más nuevo que los sondeos en modo pull y es donde hay bordes más ásperos. Menos especializado en el caso de uso de heartbeat de cron que Healthchecks.
Plataformas: Linux (Docker), Windows, macOS.
Descargar: Uptime Kuma install
Conclusión: La opción correcta cuando el hogar ya ejecuta Uptime Kuma y no desea otro panel.
5. Prometheus Node Exporter — mejores métricas para estado de systemd timer
Prometheus Node Exporter envía un recolector para el estado de la unidad y el timer de systemd. Combinado con Prometheus y Alertmanager, puedes graficar “cuándo se ejecutó correctamente este timer por última vez,” alertar sobre “no hay ejecución exitosa en los últimos N minutos,” y correlacionar con métricas del sistema amplio (CPU, disco, red). Este es el enfoque de resistencia industrial; excesivo para un hogar, exactamente la forma correcta para cualquiera que ya ejecute Prometheus.
Dónde falla: Requiere que todo el stack de Prometheus sea útil — esa es infraestructura real, no una instalación de cinco minutos. Específico de systemd para el recolector de timer; los trabajos cron necesitan un enfoque diferente.
Plataformas: Linux, Windows, macOS, FreeBSD.
Descargar: Prometheus Node Exporter releases
Conclusión: La opción correcta cuando Prometheus ya es el almacén de métricas en el hogar de laboratorio.
6. systemd — mejor detección nativa de fallos en Linux
systemd en Linux moderno tiene más manejo de fallos integrado del que la mayoría de migrantes de cron se dan cuenta. Una unidad con OnFailure= dispara otra unidad cuando falla, que puede ser un script mail, un webhook o un script que hace ping a Healthchecks. systemctl list-timers muestra el cronograma y la última ejecución, y systemctl status <unit> muestra el código de salida y la cola de registro. Para cualquiera que ya esté en timers de systemd, la mitad del monitoreo ya está en la caja.
Dónde falla: Solo te dice cuándo falló el proceso, no cuándo falló el resultado. Un script de copia de seguridad que terminó pero no hizo nada útil se ve verde para systemd.
Plataformas: Linux (distribuciones basadas en systemd).
Descargar: systemd resources
Conclusión: El mínimo correcto en cualquier servidor Linux que ejecute timers de systemd.
7. Gotify — mejor servidor de notificación push auto-alojado
Gotify es el pequeño servidor Go que convierte cualquier solicitud HTTP en una notificación push de Android. Por sí solo no detecta fallos; combinado con cualquiera de las herramientas anteriores, se convierte en la forma en que las alertas realmente llegan a un teléfono sin depender de Firebase Cloud Messaging o un servicio de notificación de terceros. Ideal para hogares donde el canal de alerta debe ser tan privado como los servidores que se monitorean.
Dónde falla: No es un monitor por sí solo. Requiere que la aplicación de Android se instale en los teléfonos receptores; el soporte de iOS depende de ntfy o similar en lugar de la propia aplicación de Gotify.
Plataformas: Linux (Docker), Windows, macOS, FreeBSD.
Descargar: Gotify install
Conclusión: El servidor de notificación push de última milla correcto para una pila de alertas auto-alojada.
Cómo elegir el correcto
- Si deseas un dead-man switch que funcione hoy: Healthchecks.io (auto-aloja una vez que crezca más allá de 20 comprobaciones).
- Si deseas telemetría de tiempo de ejecución por trabajo y estás cómodo con un servicio alojado: Cronitor.
- Si solo necesitas proteger un trabajo crítico: Dead Man’s Snitch.
- Si el servidor del hogar ya ejecuta Uptime Kuma: Uptime Kuma.
- Si Prometheus ya es el almacén de métricas: Prometheus Node Exporter.
- Si el servidor Linux ejecuta timers de systemd y deseas el monitoreo integrado: systemd.
- Si deseas que las alertas lleguen a los teléfonos del hogar sin pasar por un servicio push de terceros: Gotify.
Para la mayoría de hogar-lab, la combinación que funciona es Healthchecks (auto-alojada) como dead-man switch, conectada a Gotify para push telefónico y correo electrónico como fallback. Cualquier cosa que se ejecute como un timer de systemd obtiene una unidad OnFailure= que hace ping al mismo endpoint de Healthchecks en fallo para que las dos señales se correlacionen.
Preguntas frecuentes
¿Cuál es la diferencia entre un heartbeat y un health check?
Un heartbeat es el trabajo diciendo “me ejecuté y tuve éxito.” Un health check es un monitor que prueba el servicio para ver si responde. Los heartbeats detectan fallos silenciosos de tareas programadas; los health check detectan fallos del servicio en tiempo de ejecución. Deseas ambos.
¿Dónde debo enviar las alertas?
En algún lugar fuera de la máquina que se monitorea. El correo electrónico está bien como fallback pero no debería ser el único canal — si la máquina que ejecuta correo es la máquina que falló, la alerta nunca se va. Superpón correo electrónico más push telefónico (ntfy, Gotify, Pushover) más canal de chat (webhook de Discord, Slack) para trabajos de alta prioridad.
¿Cómo agrego un heartbeat a un trabajo de Windows Task Scheduler?
Envuelve la acción en un pequeño script de PowerShell que ejecute la tarea real, verifique el código de salida y llame a Invoke-WebRequest contra la URL de Healthchecks o Cronitor solo cuando todo tuvo éxito. El gancho “ejecuta esto al completar” de Task Scheduler no distingue entre éxito y fallo limpiamente, así que hazlo en el script.
¿Es systemd realmente suficiente para el monitoreo de Linux?
Para “¿el proceso se estrelló?” — sí. Para “¿ocurrió el resultado?” — no. Combina OnFailure= de systemd con un heartbeat que el trabajo envía solo después de que su trabajo real se complete para la imagen completa.
¿Debo seguir monitoreando cron en sí?
Sí. Cron puede estar ejecutándose y ser saludable mientras los trabajos individuales silenciosamente dejan de dispararse (sintaxis mala de crontab, cambio de permiso, usuario faltante). Uptime Kuma o Healthchecks también pueden monitorear la última hora de ejecución de cron en un servidor del hogar; si eso se vuelve antiguo, cron es lo que necesita atención.
