Supervisión de tareas programadas (cron)

Problemas con las tareas programadas

La cruel realidad de los crons es que, cuando fallan, no te avisan. La aplicación web sigue sirviendo peticiones, la página principal parece correcta, el monitor de uptime está en verde, pero en algún lugar del servidor la copia de seguridad nocturna no se ejecuta desde hace dos semanas. El trabajador de la cola se cayó tras el deploy y los trabajos pendientes se acumulan. La sincronización horaria silenciosamente pierde filas por un problema de permisos. Solo te enteras cuando algo downstream finalmente falla, normalmente justo cuando más lo necesitas. El equipo de datos quiere una exportación, soporte necesita la cola de correos, operaciones busca el backup. Entonces ya es demasiado tarde.

El monitoreo de uptime estándar no captará esto, porque no hay nada a lo que hacer ping. Un cron no expone un endpoint HTTP, no abre un puerto, no inicia un servidor. Simplemente se lanza y termina. Si deja de funcionar, no hay ninguna señal de su ausencia, hasta que empiezas a buscar.

Patrón inverso: monitorización heartbeat

La monitorización heartbeat (también llamada "interruptor del hombre muerto" o "monitorización de crons") invierte la dirección. En lugar de que nosotros comprobemos tu servicio, es tu servicio quien se registra con nosotros. Solo necesitas añadir una línea al cron: un curl a una URL única que generamos; esa URL almacena una marca temporal en cada golpe. Nosotros vigilamos la ausencia de estos pings. Si la URL no se invoca en el intervalo esperado (más el margen), lo tratamos como una ejecución perdida y enviamos un aviso.

El modelo es simple, fiable y agnóstico al lenguaje. Todo lo que puede hacer una petición HTTP se integra. Bash con curl, Python con requests, Node con fetch, PHP con curl_init, Programador de tareas de Windows con Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, eventos programados de Lambda: lo que sea. Sin SDK, sin agente, sin daemon que instalar.

Cómo configurar

En DiagnoSEO Uptime Monitoring haz clic en "Añadir monitor", elige el tipo "Heartbeat / cron". La herramienta genera una URL única con un token, algo como https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Ajusta el intervalo esperado (con qué frecuencia debe ejecutarse el job, en minutos) y el margen (cuánto retraso es tolerable antes de saltar la alarma). Guarda.

Ahora modifica tu cron para hacer ping a la URL tras cada ejecución exitosa. Hay tres estilos según tu entorno:

# Bash cron - ping solo si tiene éxito
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# O si el éxito parcial está permitido
0 3 * * * /usr/bin/backup.sh; curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Python
import requests
def main():
    do_the_work()
    requests.get('https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9', timeout=5)

# GitHub Actions
- name: Notify heartbeat
  if: success()
  run: curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9

Desde ese momento, cada ejecución exitosa nos enviará un ping y guardaremos la marca temporal. Si no vemos ningún ping dentro de intervalo + margen minutos, se abre un incidente y se envían notificaciones a todos los canales activados: Email, Telegram, Slack, Discord, SMS.

Elección de intervalo y margen

El intervalo debe coincidir exactamente con la frecuencia programada del job. Copia de seguridad nocturna a las 3:00 - intervalo 1440 minutos (24h). Sincronización horaria - 60. Worker que sondea cada 5 min - 5.

El margen absorbe el jitter natural. Los crons no se activan exactamente al nanosegundo: se ponen en cola, esperan a que termine la última ejecución, hacen back-off ante errores momentáneos. Un job de 24 horas con 1h de margen da un buen buffer sin retrasar los avisos. Un trabajador cada 5 minutos con 2 minutos de margen detecta caídas reales rápido, sin falsos positivos por un parpadeo de 30 segundos. En general: pon el margen entre el 10-50% del intervalo, según lo inestable que sea el job.

Patrones que recomendamos

• Ping solo tras el éxito. Usa && en bash: una ejecución fallida no hace ping. Nosotros detectaremos la ausencia de ping y avisaremos.
• Ping en cada iteración del bucle. Para workers long running haz ping dentro del bucle tras cada unidad de trabajo exitosa, no al final. Así, si se bloquea el worker, lo detectamos durante la ejecución.
• Un solo heartbeat por tarea lógica, no por script. Si tres scripts juntos forman una pipeline nocturna, haz ping una vez al final de la cadena. Esto da una señal clara de "pipeline viva".
• Combínalo con logs. El heartbeat indica que el job se ejecutó. Los logs muestran qué hizo. Juntos dan una visión completa.

¿Qué pasa si desaparece el heartbeat?

El incidente se abre en cuanto pasa el plazo límite. El panel de control muestra el monitor en rojo con el error "Sin heartbeat desde hace X minutos". Las notificaciones van a todos los canales configurados. Cuando llega un nuevo heartbeat, el monitor vuelve automáticamente a up, se cierra el incidente y (si tienes las alertas de recuperación activadas) recibes el aviso de "de nuevo en línea".

Todo esto se trata igual que otros monitores: heatmap, porcentaje de uptime, historial, etiquetas, búsqueda, exportación. Desde el dashboard, un monitor heartbeat es solo otra fila más, ordenable y filtrable junto con los de HTTP, ping, puerto y API.

Lista de comprobación

Añade monitor → tipo Heartbeat → copia la URL generada → añádelo al cron / worker / scheduler → elige intervalo y margen → guarda → listo. Ahora sabrás en el mismo segundo en que una tarea programada deja de funcionar, lo cual, a largo plazo, es una de las decisiones de monitorización más clave que puedes tomar.

Preguntas frecuentes

• ¿Qué es el monitoreo heartbeat / cron-job?

  Monitoreo invertido: tu tarea programada hace ping a nuestra URL cuando se ejecuta correctamente. Si no recibimos el ping en el tiempo esperado, avisamos. Así se evita el problema de fallos silenciosos: un cron job roto no lanza error ni dispara una alerta tradicional de uptime.

• ¿Cómo integro la URL de heartbeat en mi cron?

  Añade curl -fsS <heartbeat_url> al final del comando de cron. Si el comando previo falla, curl no se ejecuta y el heartbeat se omite. Alternativamente haz ping al principio y al final con rutas diferentes—tendrás señales por separado de "started" y "completed".

• ¿Qué periodo de gracia debo configurar?

  Alrededor de 2-3 veces el tiempo típico de ejecución de la tarea. Si tu backup diario dura 30 minutos, pon el margen en 90 minutos—cubre posibles retrasos sin falsos avisos. Para tareas con duración variable, configura generosamente y usa el panel para identificar posibles desvíos.

• ¿Puedo monitorizar cron jobs que se ejecutan cada hora?

  Sí—configura el intervalo en consecuencia (por ejemplo, 60 minutos con 15 minutos de margen). El monitor espera un ping al menos cada 75 minutos. Si tu tarea es más frecuente (cada 5 minutos), la URL heartbeat también lo soporta; solo ajusta el intervalo.

• ¿Funciona el heartbeat monitoring para AWS Lambda / serverless?

  Sí. Añade una llamada HTTP saliente a la URL heartbeat al final de la función Lambda. El monitor lo interpreta igual que un heartbeat de cron—mismos avisos, mismo periodo de gracia. Útil para Lambdas programadas donde las alarmas de CloudWatch no detectan fallos silenciosos de ejecución.