Por qué tus tareas cron fallan silenciosamente (y cómo detectarlo)

El problema con cron

Cron es fiable en un aspecto: ejecutará tu comando según lo programado. No es fiable en otro aspecto que importa más: no te avisa cuando tu comando falla.

Tu servidor está funcionando. El demonio cron está activo. La programación se activa puntualmente. Pero el script que le indicaste termina con un estado distinto de cero, alcanza un timeout o se queda sin memoria. Nadie lo sabe. El trabajo de cron es iniciar el proceso, no verificar que haya tenido éxito.

Esto no es un error de cron. Así fue diseñado cron. Cron es anterior a la web. Se construyó en una época en la que las tareas escribían en archivos de registro y un humano las revisaba periódicamente. Ese modelo no escala a la infraestructura moderna donde un desarrollador gestiona docenas de tareas programadas en múltiples servidores.

Lo que te cuestan los fallos silenciosos de cron

Un fallo silencioso de copia de seguridad significa que lo descubres cuando necesitas la copia. Quizás tres semanas después, tras un incidente de corrupción de base de datos. La brecha entre el momento en que la copia dejó de funcionar y cuando la necesitabas son datos que no puedes recuperar.

Un fallo silencioso de cola de correo significa que los clientes dejan de recibir notificaciones. Restablecimientos de contraseña, confirmaciones de pedido, recibos de facturación. Nadie se queja al principio porque nadie sabe lo que falta. Cuando te das cuenta, tienes miles de correos sin entregar y usuarios confundidos.

Un fallo silencioso de exportación de datos significa que tus analíticas son incorrectas. Tus dashboards muestran tendencias basadas en datos obsoletos. Tomas decisiones con información incompleta. El error se agrava cuanto más tiempo pasa sin detectarse.

Por qué la monitorización de disponibilidad no detecta esto

Tu monitor de disponibilidad dice que tu servidor está activo. Tu API devuelve 200. Tu dashboard carga. Todo está bien según tu panel de monitorización.

Pero ninguna de esas comprobaciones te dice si la copia de seguridad de anoche se completó. No saben si tu conciliación de facturación se ejecutó. No saben si el pipeline de datos que alimenta tus analíticas terminó.

La monitorización de disponibilidad responde: «¿Puedo alcanzar este endpoint?». La monitorización heartbeat responde: «¿Se ejecutó esta tarea?». Son preguntas complementarias. Necesitas ambas.

Cómo funciona la monitorización heartbeat

La monitorización heartbeat es simple. Cada tarea programada recibe una URL única con un token secreto. Al final de tu tarea, añade una sola línea que haga ping a esa URL:

curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN

Si el ping llega dentro de la ventana esperada, la verificación heartbeat se aprueba. Si la ventana se cierra sin ping, el monitor activa una alerta.

Tú configuras el intervalo esperado. Si tu copia de seguridad se ejecuta cada 6 horas, establece el intervalo en 6 horas. Añade un período de gracia si la duración de la tarea varía. Un período de gracia de 10 minutos significa que el monitor no alerta a menos que el ping tenga 10 minutos de retraso.

Esa es toda la configuración. Una URL. Un comando curl. Cero archivos de configuración.

Configurándolo en la práctica

Aquí tienes una entrada cron para una copia de seguridad nocturna de base de datos:

0 2 * * * /usr/local/bin/backup-db.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN

El && es importante. Significa: «Ejecuta curl solo si el script de copia de seguridad termina con estado 0 (éxito)». Si la copia de seguridad falla, curl nunca se ejecuta. No llega ningún ping. Recibes una alerta.

Si quieres monitorizar que el script se ejecutó (incluso si falló), usa ; en lugar de &&, y añade manejo de errores dentro del script para informar del estado. Pero para la mayoría de los casos de uso, && es lo que necesitas. Te importa el éxito, no solo la ejecución.

Qué monitorizar con heartbeats

Comienza con los trabajos que más dolerían si fallaran silenciosamente:

Copias de seguridad de base de datos: Este es el caso de uso más común y el que tiene el mayor coste de fallo. Una copia de seguridad que no sabes que falta es peor que no tener copia en absoluto.

Colas de entrega de correo: Si tus correos transaccionales o de marketing dejan de enviarse, quieres saberlo en minutos, no en horas.

Facturación y generación de facturas: Una facturación fallida significa ingresos perdidos. Un heartbeat en tu trabajo de facturación lo detecta antes de fin de mes.

Sincronizaciones y exportaciones de datos: Si tu pipeline de analíticas o la sincronización de tu almacén de datos falla, tus informes son incorrectos. Un heartbeat te avisa dentro del intervalo esperado.

Renovación de certificados: Si usas certbot o herramientas similares con renovación automática, añade un heartbeat. La caducidad de certificados es una de las causas de tiempo de inactividad más prevenibles.

Rotación y limpieza de logs: Si la rotación de logs falla, tu disco se llena. Tu servidor se cae. Un heartbeat detecta el fallo de rotación antes de que el disco esté lleno.

Monitorización heartbeat vs. servicios de monitorización cron

Herramientas como Healthchecks.io y Cronitor se centran exclusivamente en la monitorización de tareas cron y programadas. Lo hacen bien. Algunas añaden funciones como seguimiento de duración de tareas y tendencias de rendimiento.

PingWatchdog incluye monitorización heartbeat junto con monitorización de disponibilidad y monitorización SSL en una sola plataforma. No necesitas una herramienta separada para tareas cron. Monitorizas tus sitios web, APIs, certificados SSL y tareas programadas desde un solo dashboard con un solo sistema de alertas.

Esto importa porque el mismo equipo que monitoriza la disponibilidad normalmente gestiona las tareas cron. Consolidar herramientas significa menos dashboards que revisar, menos canales de alerta que configurar y menos suscripciones que gestionar.

Compara PingWatchdog con Healthchecks.io para ver cómo nuestra monitorización heartbeat se compara con la monitorización de disponibilidad y las páginas de estado.

Monitorización de cron en contenedores y Kubernetes

Si ejecutas tareas cron dentro de contenedores Docker o CronJobs de Kubernetes, el mismo patrón heartbeat funciona. Añade un comando curl al final del punto de entrada de tu contenedor o del comando de tu CronJob.

Para Kubernetes:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: db-backup
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: your-backup-image
            command:
            - /bin/sh
            - -c
            - "/backup.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN"
          restartPolicy: OnFailure

El mismo principio se aplica a eventos programados de AWS Lambda, Google Cloud Scheduler, timers de systemd o cualquier otro planificador. Si tu tarea puede hacer una petición HTTP, puede enviar un heartbeat.

Empieza ahora

PingWatchdog incluye monitorización heartbeat en todos los planes. El plan gratuito te da 3 monitores heartbeat. Los planes de pago llegan hasta 25.

Más información sobre las funciones de monitorización heartbeat o configura tu primer monitor.