Por qué los cron jobs fallan en silencio — y cómo enterarte
El cron del sistema no sabe si tu job tuvo éxito. Aquí se explica por qué los trabajos planificados fallan sin dejar rastro y los patrones que lo solucionan.
Hay un tipo de incidencia que es peor que una ruidosa: la silenciosa. Un job planificado deja de funcionar, nada alerta, y semanas después descubres el daño — un backup vacío, una facturación que nunca se ejecutó, un índice de búsqueda congelado en el tiempo. Este artículo explica por qué sucede eso y cómo detenerlo.
Cron dispara y olvida
El problema fundamental es que el cron de Unix es un lanzador, no un
supervisor. Ejecuta tu comando al minuto acordado y sigue adelante. No le importa
si el comando salió con 0 o con 1, si se colgó para siempre o si imprimió un stack
trace. No existe ninguna noción integrada de éxito, fallo o “esto debería haber
corrido hace una hora y no lo hizo.”
Así que un job puede fallar de todas las maneras habituales — una dependencia está caída, las credenciales expiraron, el disco se llenó, un despliegue cambió una ruta — y desde el punto de vista de cron, no ha pasado nada.
Los tres modos de fallo que nadie detecta
- Corrió y falló. El script arrancó pero salió con código distinto de cero. Cron no lo nota; como mucho envía un email al buzón local de root, que nadie lee.
- Se colgó. El job empezó y nunca terminó, reteniendo un bloqueo o con una fuga de memoria. La siguiente ejecución planificada puede que ni siquiera arranque.
- Nunca corrió. El servidor se reinició, el crontab se editó mal o la zona horaria cambió por el horario de verano. El job simplemente no se está ejecutando — y la ausencia es lo más difícil de detectar.
Los dos primeros casos requieren que el job informe de su resultado. El tercero no puede detectarse en la máquina en absoluto, porque lo que debería avisarte es precisamente lo que está roto.
La solución: heartbeats y registros de ejecución
Dos patrones cierran la brecha.
Los heartbeats desplazan la pregunta “¿corrió?” fuera de la máquina que podría estar caída. Tu job hace ping a un servicio externo cuando termina; si el ping no llega según lo previsto, el servicio te alerta. Lo importante es que esto detecta el caso “nunca corrió” — el silencio es la señal.
# al final de tu job
curl -fsS https://ping.steadycron.com/<tu-ping-token>
Los registros de ejecución capturan el resultado de cada ejecución — estado, duración, salida — de modo que “¿tuvo éxito el job de las 3am, y qué devolvió?” tiene una respuesta días después.
El lugar de SteadyCron
SteadyCron hace ambas cosas. Puede ejecutar tus HTTP jobs con retries y timeouts, registrando cada invocación, y puede monitorear el cron que ya ejecutas mediante heartbeats — alertando sobre ejecuciones perdidas, fallidas y bloqueadas por email, Slack, Discord, Telegram y webhooks.
Si alguna vez te has enterado de un job roto a través de un cliente en lugar de desde un dashboard, ese es el problema para el que lo construimos.
Empieza gratis o lee la guía de monitoreo de heartbeat.