Para monitorizar un cron job, dale un heartbeat: una URL única a la que la tarea hace una petición cada vez que termina. Un servicio de monitorización espera esa petición a intervalos regulares. Si no llega a tiempo, porque la tarea no se ejecutó, falló o se quedó colgada, recibes una alerta. Solo hace falta una línea más en tu crontab.
Esta guía explica cómo funcionan los heartbeats, cómo añadir uno y cómo elegir los ajustes adecuados.
Por qué los cron jobs necesitan su propia monitorización
Cron es fiable para lanzar comandos y no dice nada de lo que pasa después. Si un script de copia de seguridad falla a las 02:00, no se rompe nada visible. La web sigue en línea y las comprobaciones de uptime siguen en verde. Te enteras semanas después, cuando necesitas la copia y no está.
Fallos silenciosos típicos:
El servidor estaba caído o reiniciándose a la hora programada.
El crontab se sobrescribió durante un despliegue o una migración de servidor.
El comando falla con cron porque PATH u otras variables de entorno son distintas de las de tu shell.
El script se ejecuta pero se queda colgado en un bloqueo, una llamada de red o un disco lleno.
Las credenciales caducaron, así que la tarea arranca y termina con un error que nadie lee.
La monitorización de uptime no ve nada de esto, porque no se rompe nada público. Un heartbeat funciona al revés: en lugar de que el monitor compruebe tu tarea, es tu tarea la que da señales al monitor.
Cómo funciona un heartbeat
Creas un monitor de heartbeat y obtienes una URL única.
Defines cuándo se espera que se ejecute la tarea, como un intervalo (por ejemplo, cada 24 horas) o con la propia programación del crontab de la tarea, con algo de margen para las ejecuciones lentas.
La tarea hace una petición GET o POST a la URL cuando termina.
Si no llega ninguna petición a tiempo, se abre un incidente y se envían las alertas.
Cuando llega el siguiente ping, el heartbeat se recupera y recibes un aviso de recuperación.
Los monitores de cron de Uptimecheck funcionan así. Aceptan la programación del crontab en tu zona horaria, admiten pings de inicio y de fin en un mismo monitor, avisan cuando una ejecución supera su tiempo máximo y pueden registrar el código de salida y la salida de la tarea. Las alertas llegan por email, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks y notificaciones push en el móvil, en todos los planes.
Cómo añadir un heartbeat a un crontab
Supongamos que una copia de seguridad se ejecuta cada noche a las 02:30:
30 2 * * * /usr/local/bin/backup.sh
Añade el ping después de la tarea, encadenado con && para que solo se ejecute si la copia sale bien:
30 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 https://heartbeat.example.com/your-unique-id > /dev/null
Qué hacen las opciones de curl:
-f hace que curl falle ante errores HTTP en lugar de tratarlos como un éxito.
-s lo mantiene en silencio, y -S sigue mostrando los errores si algo va mal.
-m 10 deja de esperar a los 10 segundos, para que una red lenta nunca bloquee la tarea.
–retry 3 reintenta ante problemas de red breves.
Sustituye el marcador por la URL exacta de tu monitor de heartbeat.
Ping desde dentro de un script
En scripts más largos, pon el ping al final del propio script, después de los pasos importantes:
#!/usr/bin/env bash
set -euo pipefail
pg_dump northwind > /backups/northwind-$(date +%F).sql
gzip /backups/northwind-$(date +%F).sql
curl -fsS -m 10 –retry 3 https://heartbeat.example.com/your-unique-id > /dev/null
Con set -e el script se detiene en el primer comando que falla, así que el ping solo se envía cuando todo lo anterior ha funcionado.
Otros programadores de tareas
Los heartbeats no se limitan a cron. Cualquier cosa capaz de hacer una petición HTTP puede enviar un ping: temporizadores de systemd, el Programador de tareas de Windows con Invoke-WebRequest de PowerShell, un CronJob de Kubernetes, un pipeline de CI o una función programada de tu aplicación.
Cómo elegir el intervalo
El intervalo debe coincidir con la programación: 24 horas para una tarea nocturna, 1 hora para una tarea horaria. Deja margen para la variación normal en lo que tarda la tarea. Si una copia de seguridad suele tardar 20 minutos pero a veces 50, una hora extra de margen evita falsas alarmas sin ocultar durante mucho tiempo un fallo real.
Empieza con un margen generoso, observa durante una o dos semanas cuánto tardan realmente las ejecuciones y luego ajústalo. Si tu monitor acepta la propia expresión del crontab, como el de Uptimecheck, pega la programación y elige la zona horaria del servidor. Así las horas esperadas siguen exactamente la programación y el margen se convierte en un periodo de gracia.
Heartbeats frente a otros enfoques
Hay otras formas de vigilar las tareas programadas, todas con carencias:
Email desde cron. Cron puede enviar por email la salida de un comando, pero solo cuando la tarea se ejecuta y produce salida. Si la tarea no llega a arrancar, no hay email. Y la mayoría de estos emails no los lee nadie.
Monitorización de logs. Útil para encontrar errores, pero una tarea que nunca se ejecutó no escribe ninguna línea de log que buscar.
Comprobar resultados. Algunos equipos comprueban si existe un archivo de copia de seguridad o si se actualizó una tabla. Funciona, pero exige comprobaciones a medida para cada tarea.
Un heartbeat funciona igual para todas las tareas y detecta el caso que se les escapa a los demás: la tarea que no se ejecutó en absoluto.
Tareas de larga duración
En tareas que tardan mucho, como grandes copias de seguridad o migraciones de datos, envía un ping al principio además de al final. Si llega el ping de inicio pero no el de fin, la tarea se quedó colgada o falló a medias. Eso te dice dónde mirar antes de abrir un solo archivo de log.
En Uptimecheck ambos pings van al mismo monitor: haz la petición a la URL con /start añadido cuando empiece la tarea, y a la URL tal cual cuando termine. El tiempo entre ambos se registra como duración de la ejecución y, si defines un tiempo máximo de ejecución, recibes una alerta cuando una ejecución tarda más.
Qué tareas merecen un heartbeat
No todas las tareas lo necesitan. Prioriza aquellas cuyo fallo solo notarías más tarde:
Copias de seguridad de bases de datos y archivos.
Importaciones y exportaciones de datos, como feeds de productos o sincronizaciones contables.
Emisión de facturas, renovaciones y tareas de facturación.
Tareas de renovación de certificados.
Limpiezas que evitan que se llene un disco.
Generación de informes de los que dependen otras personas.
Dale a cada tarea su propio heartbeat. Uno compartido te dice que algo no se ejecutó, pero no qué.
Qué hacer cuando falta un heartbeat
Cuando llegue una alerta de heartbeat:
Comprueba si cron lanzó la tarea. Mira en el log de cron o del sistema.
Ejecuta el comando a mano con el mismo usuario que usa cron y lee la salida.
Revisa el entorno. Usa rutas absolutas o define PATH al principio del crontab.
Revisa los recursos. Un disco lleno o la memoria agotada detienen muchas tareas. La monitorización de servidores muestra el disco, la RAM y la carga en el momento del fallo.
Revisa la red saliente. Un cambio en el firewall puede bloquear el ping aunque la tarea funcione. Si la tarea se ejecutó pero el ping falló, el error de curl aparece en la salida de la tarea.
Redirige la salida de la tarea a un archivo de log, para que siempre haya algo que leer:
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1 && curl -fsS -m 10 https://heartbeat.example.com/your-unique-id > /dev/null
También puedes enviar el resultado con el ping. En Uptimecheck, terminar la URL con el código de salida (/0 significa éxito; cualquier otro, fallo) indica cómo terminó la tarea, y el cuerpo de un POST se guarda como salida de la tarea y se muestra con la alerta. Esta línea envía un ping al inicio, ejecuta la tarea e informa de su código de salida y su salida:
30 2 * * * curl -fsS -m 10 –retry 3 -o /dev/null https://heartbeat.example.com/your-unique-id/start; /usr/local/bin/backup.sh > /tmp/backup.log 2>&1; curl -fsS -m 10 –retry 3 –data-binary @/tmp/backup.log -o /dev/null https://heartbeat.example.com/your-unique-id/$?
Checklist para monitorizar cron jobs
Haz una lista de las tareas programadas importantes, en todos los servidores.
Crea un heartbeat por tarea.
Envía el ping cuando el trabajo haya salido bien, encadenado con && o al final de un script con set -e.
Ajusta el intervalo a la programación, con margen para las ejecuciones lentas.
Guarda la salida de las tareas en un archivo de log.
Envía las alertas a un canal que alguien lea, también por la noche para las tareas críticas.
Revisa el historial de heartbeats después de despliegues y migraciones de servidor.
Resumen
Cron no te avisa cuando una tarea falla. Un heartbeat, sí. Una línea de curl por tarea convierte los fallos silenciosos en alertas, y el historial te muestra exactamente cuándo se ejecutó cada tarea por última vez.
Los heartbeats están incluidos en todos los planes de Uptimecheck, junto con la monitorización de uptime, SSL, dominios, DNS y servidores. Pruébalo gratis durante 14 días, sin tarjeta de crédito.