Cómo monitorear cron jobs: 5 patrones de heartbeat

Cron es excelente lanzando cosas según un plan y catastrófico avisándole cuando no las lanza. Una copia de seguridad que deja de ejecutarse rara vez lanza un error que usted vea. Simplemente no hace nada en silencio y lo descubre semanas después, cuando necesita la copia y no está. Este es el problema del fallo silencioso, y por eso cada tarea programada que importe necesita una comprobación por heartbeat.

Un heartbeat (o "dead man's switch") invierte la lógica. En lugar de avisar cuando algo va mal, su tarea hace ping a un endpoint de monitoreo cuando todo va bien. Si el ping esperado no llega a tiempo, el monitor avisa. Sin ping, sin noticias, gran problema.

Abajo hay cinco patrones, del más sencillo al más robusto. Todos asumen que tiene una URL de heartbeat de su herramienta de monitoreo.

Patrón 1: el dead man's switch clásico

La configuración más simple posible. Su tarea llama a una URL al terminar. Si el monitor no recibe noticias en la ventana esperada, avisa.

# Copia diaria a las 02:30, ping al terminar
30 2 * * * /usr/local/bin/backup.sh && curl -fsS https://su-monitor/ping/abc123

El && importa: curl solo se ejecuta si backup.sh termina con código 0 (éxito). Si la copia falla, no se envía ningún ping y el monitor lo detecta. Las opciones -fsS hacen que curl falle en silencio ante errores HTTP, pero sigue mostrando los problemas reales.

Punto débil: solo confirma que el script se ejecutó y terminó en cero. Si el script se traga sus propios errores y aun así termina en cero, obtiene un falso "todo en orden".

Patrón 2: ping solo en un éxito real

Haga explícita la señal de éxito en lugar de fiarse del encadenamiento de códigos de salida en el shell. En scripts de varios pasos queda más claro.

#!/bin/bash
set -euo pipefail   # ante cualquier error, falla a lo grande
run_the_backup
verify_the_backup    # verifica de verdad que la salida existe y tiene sentido
curl -fsS https://su-monitor/ping/abc123   # solo se llega aquí si todo lo anterior pasó

set -euo pipefail significa que cualquier comando fallido interrumpe el script antes del ping. Añadir un paso de verificación real (existe el fichero de copia, mide más de cero bytes) cierra el agujero del "terminó en cero pero no hizo nada" del Patrón 1.

Patrón 3: el envoltorio de código de salida

Cuando no puede modificar la tarea en sí (un binario de terceros, un script de proveedor), envuélvala. El envoltorio señala el inicio, lanza la tarea y reporta el código de salida.

#!/bin/bash
URL=https://su-monitor/ping/abc123
curl -fsS "$URL/start"                  # señal "he arrancado"
/opt/vendor/report-generator            # la tarea que no controla
EXIT=$?
curl -fsS "$URL/$EXIT"                   # reporta el código de salida

Señalar el inicio permite al monitor medir también la duración del run y detectar una tarea que arrancó pero nunca terminó (se atascó). Reportar el código de salida le permite distinguir "salió bien" de "salió y falló".

Patrón 4: ping condicional (haga ping solo cuando el trabajo tuvo sentido)

Algunas tareas se ejecutan según un plan pero solo hacen trabajo real a veces (un procesador de cola que a menudo encuentra la cola vacía). No quiere una alerta de "heartbeat ausente" cuando la tarea legítimamente no hizo nada. Haga ping solo cuando el trabajo real ocurrió, y amplíe el plan en consecuencia.

#!/bin/bash
PROCESSED=$(process_queue)
if [ "$PROCESSED" -gt 0 ]; then
  curl -fsS "https://su-monitor/ping/abc123?count=$PROCESSED"
fi

Ajuste el periodo esperado del monitor al hueco real más largo entre ejecuciones reales. El peaje es la sensibilidad: una ventana más larga significa una detección más lenta, así que úselo solo cuando el trabajo irregular sea realmente esperado.

Patrón 5: jitter y ventanas de gracia

Los planes reales derivan. Una tarea fijada a las 02:00 puede arrancar a las 02:00:04 por la carga, y la duración de una tarea diaria varía. Si el monitor espera el ping exactamente en el intervalo, el jitter normal le sobresalta sin motivo.

La solución es un periodo de gracia: dígale al monitor que, tras la hora esperada, aguarde un margen más antes de avisar. Una copia diaria que suele tardar 8 minutos puede usar una ventana de gracia de 20 minutos. También conviene cierto jitter en la propia planificación cuando tiene muchas tareas, para que no carguen el mismo recurso en el mismo segundo:

# Añade un pequeño retardo aleatorio (0-59s) para repartir las tareas de las 02:00
0 2 * * * sleep $((RANDOM % 60)) && /usr/local/bin/backup.sh && curl -fsS https://su-monitor/ping/abc123

Las ventanas de gracia son la diferencia entre un monitor en el que confía y uno que silencia tras la tercera falsa alarma. Ajuste la gracia para que supere cómodamente el peor tiempo de ejecución real de la tarea, no su media.

Vista rápida

Cómo llevarlo a la práctica

Empiece con el Patrón 1 en su tarea más importante hoy mismo (una copia de seguridad, un run de facturación, una sincronización de datos). Añada verificación (Patrón 2) y una ventana de gracia (Patrón 5) antes de empezar a depender de ella. Encontrará una guía más detallada para configurar el heartbeat en nuestra guía monitorear cron jobs con heartbeat.

Si su tarea se comunica con un servicio por un puerto concreto, compruebe primero su alcanzabilidad con el verificador de puertos gratuito. Y cuando esté listo para monitorear las tareas programadas junto a webs y API en un solo lugar, vea cómo funciona el monitoreo de disponibilidad de ePulz.io - la prueba de 7 días es gratis, sin tarjeta.