Cómo monitorear cron jobs y recibir una alerta cuando fallan

Cron inicia cada comando a su hora y se olvida de él. No avisa cuando un job falla, y si un job deja de ejecutarse porque el servidor estaba apagado, cron se detuvo o alguien reemplazó el crontab, no dice nada. Estas son las formas de enterarse, y lo que se le escapa a cada una.

Qué puede salir mal

• El job falla. Se ejecuta y termina con un código de salida distinto de 0 (qué significa cada código está en los códigos de salida de cron).
• El job no se ejecuta. Cron está detenido, el servidor está caído, el crontab se sobrescribió, o el horario o la zona horaria no son los que crees.
• El job se cuelga. Empieza y nunca termina, o tarda mucho más de lo normal.
• Dos ejecuciones se solapan. Una empieza mientras la anterior sigue corriendo (cómo evitarlo está en cómo evitar que los cron jobs se solapen).

Un buen método detecta los tres primeros casos. La mayoría solo detecta el primero.

MAILTO: el correo de cron

Cron envía por correo lo que imprime un job a la dirección de MAILTO:

MAILTO=ops@example.com
0 3 * * * /ruta/a/backup.sh

• Necesita un servidor de correo en la máquina, como Postfix o msmtp, que pueda entregar a tu dirección. La mayoría de los servidores y contenedores no lo tienen: en Debian y Ubuntu, cron registra No MTA installed, discarding output y el correo se pierde.
• Envía un correo cuando el job imprime algo, no cuando falla. Un job que imprime en cada ejecución te llena la bandeja y terminas ignorándolo; uno que falla sin imprimir nada no envía nada.

Para recibir un correo solo cuando el job falla, guarda la salida en un archivo y, si el job falla, imprime una línea con su código de salida y después la salida:

MAILTO=ops@example.com
0 3 * * * /ruta/a/backup.sh > /tmp/backup.log 2>&1 || { echo "backup.sh falló con código $?"; cat /tmp/backup.log; }

La línea del echo asegura que llegue un correo aunque el job falle sin imprimir nada. Aun así, no puede avisarte que el job no se ejecutó: sin ejecución no hay salida, y sin salida no hay correo. Cómo hacer que los correos lleguen, paso a paso, está en cómo recibir un correo cuando un cron job falla.

Logs

El log del sistema muestra cuándo cron inició cada comando, pero no cómo terminó. Para tener también la salida y el código de salida de cada ejecución, el job tiene que escribirlos en su propio log, como se explica en los logs de cron.

Los logs sirven para investigar una ejecución, pero no avisan: encuentras el problema solo cuando los revisas, normalmente después de que alguien nota que falta el backup de la semana pasada.

Una alerta desde el propio job

La línea del crontab puede enviar una alerta cuando el job falla, por ejemplo a un webhook entrante de Slack:

0 3 * * * /ruta/a/backup.sh || curl -fsS -m 10 -H 'Content-Type: application/json' -d '{"text":"backup.sh falló"}' https://hooks.slack.com/services/...

Avisa de las fallas al instante y sin servidor de correo. Pero, igual que MAILTO, depende de que el job se ejecute: si cron o el servidor están caídos, nadie envía la alerta, y el silencio se ve igual que un éxito.

Heartbeats

Un heartbeat es una señal que tu job envía a un servicio de monitoreo cada vez que se ejecuta. El servicio espera recibirla dentro de un plazo y te alerta si no llega. Como la alerta sale de otra máquina, te enteras incluso cuando el servidor está apagado, cron está detenido o el crontab desapareció. También se le llama dead man’s switch.

Qué buscar, en un servicio o en tu propia solución:

• Enviar el código de salida, no solo que el job se ejecutó. Con backup.sh && curl ..., una falla solo se nota cuando vence el plazo; si envías el código con $?, la alerta llega al instante y con el código.
• Enviar también el inicio. Con una señal al empezar y otra al terminar, el servicio distingue un job que se colgó de uno que no empezó, mide cuánto tarda cada ejecución y detecta cuando dos se solapan.
• Elegir cuánto esperar. Un job que a veces tarda 40 minutos necesita más margen que uno que tarda segundos.
• Que el monitoreo no rompa el job. Llama al servicio con un límite de tiempo, como curl -m 10, para que una red lenta no retenga el job.
• Alertas que no te inunden. Un job que falla cada minuto no debería enviarte un correo cada minuto.

Puedes armar tu propia solución, con un script en otro servidor que revise un archivo que el job actualiza, pero entonces ese script también necesita monitoreo. Por eso la mayoría usa un servicio.

Cuál usar

Vale la pena mantener los logs y MAILTO para investigar una ejecución. Para enterarte también de que un job dejó de ejecutarse, usa un monitor que espere una señal dentro de un plazo.

Servicios

Estos servicios reciben heartbeats y te avisan cuando un job falla o no envía su señal a tiempo. Todos tienen un plan gratis:

• Healthchecks.io: de código abierto (BSD), así que también puedes instalarlo en tu servidor.
• Cronitor: cron jobs, heartbeats, chequeos de sitios web y APIs, y páginas de estado.
• Dead Man’s Snitch: avisa cuando una tarea programada no se ejecuta cuando debía.
• Better Stack: monitoreo de cron como parte de una plataforma de uptime, incidentes y logs.
• CronDrive, este sitio: señales al inicio y al final con el código de salida, alertas por correo, Slack o webhooks (Discord, Microsoft Teams, Telegram, PagerDuty o tu propia URL), ejecuciones que se solapan, y un servidor MCP para que un agente de IA configure el crontab de un servidor.

Si necesitas tener todo en tus propios servidores, Healthchecks.io es el que debes mirar.

Monitorear un cron job con CronDrive

Agrega una llamada antes y otra después del comando, con el código de salida:

0 3 * * * curl -fsS -m 10 https://job.crondrive.com/<token>/start/$$; /ruta/a/backup.sh; curl -fsS -m 10 https://job.crondrive.com/<token>/end/$?/$$

$? es el código de salida del job, y $$ un número que une cada inicio con su fin. No tienes que escribirla a mano: crea el job en CronDrive con el horario de tu crontab y te entrega esta línea con el token del job en lugar de <token>. Pégala en lugar de la anterior y activa el monitoreo; la próxima ejecución aparecerá en el historial del job. Más detalles en la documentación.

CronDrive te avisa cuando el código no es 0, o cuando una ejecución no empieza o no termina en los minutos que permites. Si varias ejecuciones seguidas salen mal, recibes las tres primeras alertas y luego nada hasta que una salga bien; entonces recibes un aviso de que el job volvió a funcionar.