Monitoring de cron jobs y workers en background via heartbeat

En resumen: El monitoring HTTP clásico no detectará que tu cron nocturno enviando facturas o sincronizando datos cayó. El patrón heartbeat invierte la dirección de comunicación - el cron se reporta al monitoring, y si no llama en el tiempo esperado, recibes una alerta.

El problema: tareas en background sin endpoint HTTP

Un backend típico tiene caminos:

• Solicitudes web (HTTP/HTTPS al servidor) - monitorizas con uptime check.
• Cron jobs (backup diario, facturación mensual, sync horaria) - no tienen endpoint HTTP, el monitoring externo no los ve.
• Workers (Celery, BullMQ, Sidekiq) consumiendo una cola - también sin HTTP.

Si el cron cae (cambias crontab y haces un typo, el servidor no tiene disco, falta una variable de entorno, un upgrade de dependencia rompió el import), nadie te avisa - hasta que el lunes por la mañana notas que las facturas no se enviaron el fin de semana.

Patrón heartbeat: el cron pingea el monitoring

El principio es opuesto al monitoring normal:

1. En el servicio de monitoring creas un monitor heartbeat con intervalo esperado (p.ej. "cada 60 minutos").
2. Recibes una URL heartbeat única: https://epulz.io/heartbeat/abc123xyz.
3. En tu cron job al final de una ejecución exitosa llamas esta URL (HTTP GET o POST).
4. Si el ping no llega en el tiempo esperado (+ periodo grace), el monitoring te alerta.

Ejemplo práctico: bash cron

# /etc/crontab
0 3 * * * www-data /usr/local/bin/backup.sh && curl -fsS -m 10 \
  https://epulz.io/heartbeat/abc123xyz > /dev/null

La clave es el && - el heartbeat se envía solo si backup.sh termina con código de salida 0. Si el script falla, el ping no llegará, y en una hora recibes una alerta.

Tip: Para cobertura más exhaustiva añade también un heartbeat "start":

curl -fsS -m 10 https://epulz.io/heartbeat/abc123xyz/start > /dev/null
/usr/local/bin/backup.sh
EXIT=$?
curl -fsS -m 10 "https://epulz.io/heartbeat/abc123xyz?exit=$EXIT" > /dev/null

El monitoring entonces distingue "empezó y no terminó" (script congelado) de "no empezó en absoluto" (el cron job no se ejecutó).

Python: requests + try/except

import os, requests
HEARTBEAT_URL = os.environ["HEARTBEAT_URL"]

def sync_data():
    # tu lógica
    pass

try:
    sync_data()
    requests.get(HEARTBEAT_URL, timeout=10)
except Exception as e:
    # El heartbeat no se envía - el monitoring te alertará
    raise

Node.js: async / await

const HEARTBEAT_URL = process.env.HEARTBEAT_URL;

async function nightlyJob() {
  await processInvoices();
  await fetch(HEARTBEAT_URL, { signal: AbortSignal.timeout(10000) });
}

nightlyJob().catch(err => {
  console.error(err);
  process.exit(1);
});

Periodo grace: cuánto tiempo dar antes de la alerta

El monitor heartbeat necesita tolerancia - el cron a veces tarda más de lo habitual, la red tiene latencia, la sync NTP puede estar ligeramente desplazada. El periodo grace es el tiempo tras el intervalo esperado durante el cual el monitoring todavía espera.

Valores prácticos:

• Hourly cron: intervalo 60 min + grace 10 min
• Daily backup (promedio 20 min): intervalo 1440 min + grace 60 min
• Weekly report: intervalo 10080 min + grace 360 min (6 h)

Grace demasiado ajustado = alertas falso-positivo. Demasiado holgado = aviso retrasado cuando realmente cae.

Donde el patrón heartbeat ayuda más

• Backups nocturnos de DB
• Sincronización con APIs externos (CRM, accounting, payment)
• Cálculos de informes
• Tareas cleanup (borrar sesiones viejas, logs, archivos temporales)
• Ciclo healthcheck de workers de larga duración
• Emails programados, newsletters, facturación

Conclusión

Las tareas en background son a menudo más críticas que el propio web, pero siguen siendo punto ciego del monitoring. El patrón heartbeat requiere 5 minutos de implementación (añadir curl al final de la línea cron) y proporciona la misma tranquilidad que el monitoring uptime para el frontend.

Empieza a monitorear cron jobs

ePulz.io soporta heartbeat checks con periodo grace configurable. 7 días gratis.

Iniciar monitorización →