Logs de cron: dónde verlos y cómo saber si un job se ejecutó

Los registros de cron permiten comprobar si se inició un comando, pero no siempre muestran si terminó correctamente. Aquí encontrarás dónde consultarlos según tu sistema, y cómo guardar la salida y el resultado de cada job.

Ubuntu y Debian

Con rsyslog instalado, cron escribe en /var/log/syslog:

grep CRON /var/log/syslog
zgrep CRON /var/log/syslog*      # también los archivos anteriores, rotados

Sin rsyslog, como en Debian 12 y en muchas imágenes mínimas, el log está en el journal de systemd:

journalctl -u cron --since today
journalctl -u cron --since "2026-10-15 03:00" --until "2026-10-15 04:00"

Cada comando que cron inicia deja una línea como esta (el formato de la fecha depende del sistema):

2026-10-16T03:00:01.571187-03:00 server CRON[12345]: (root) CMD (/usr/local/bin/backup.sh)

(root) es el usuario del crontab, y CMD el comando que cron inició.

RHEL, CentOS, Fedora, Rocky y AlmaLinux

Cronie escribe en /var/log/cron, y en el journal:

sudo grep CMD /var/log/cron
sudo tail -n 50 /var/log/cron
journalctl -u crond --since today

Los jobs de /etc/cron.daily

Los scripts de /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly y /etc/cron.monthly no aparecen por su nombre: el log muestra el comando run-parts que los ejecuta todos. En Debian y Ubuntu con anacron instalado, los diarios, semanales y mensuales los ejecuta anacron, y su log va aparte:

journalctl -u anacron --since "2 days ago"

Para ver qué scripts ejecutaría run-parts, sin ejecutarlos:

run-parts --test /etc/cron.daily

En un contenedor de Docker

Un contenedor normalmente no tiene syslog, y el cron de las imágenes de Debian y Ubuntu solo registra ahí, así que docker logs no lo muestra (más en cómo ejecutar cron jobs en un contenedor de Docker). Puedes:

• Enviar la salida de cada job a la salida del contenedor, que docker logs sí muestra. Esta línea, con el usuario root después del horario, va en /etc/crontab o en un archivo de /etc/cron.d/:

  0 3 * * * root /app/job.sh > /proc/1/fd/1 2>&1

• Usar un cron que registre en la salida, como el crond de BusyBox en las imágenes de Alpine, o supercronic:

  crond -f -l 2 -L /dev/stdout

Lo que el log no dice

Por defecto, una línea CMD solo significa que cron inició el comando. No dice si terminó, cuánto tardó ni qué código de salida devolvió. Para saberlo, guarda la salida y el código de salida de cada job en un archivo:

0 3 * * * { date; /ruta/al/job.sh; code=$?; echo "exit code $code"; exit $code; } >> "$HOME/job.log" 2>&1

Cada ejecución agrega la fecha, todo lo que imprimió el job, incluidos los errores, y su código de salida: 0 si salió bien. La línea termina con el código de salida del propio job, así que lo que se ejecute después, o lo revise, sigue viendo si el job falló.

Opcional: registrar el final y las fallas

En Debian y Ubuntu, cron también puede registrar el final de cada job y los que fallan, con su opción -L: la suma de 1 (inicio), 2 (final), 4 (fallidos, con código de salida distinto de 0) y 8 (número de proceso). Para registrar todo, ejecuta sudo systemctl edit cron, agrega estas líneas y reinicia cron con sudo systemctl restart cron:

[Service]
Environment="EXTRA_OPTS=-L 15"

Aun así, el log no guarda lo que imprimió el job: para eso, guarda su salida como arriba.

Cómo saber si un job se ejecutó

1. Busca su línea CMD cerca de la hora en que debía ejecutarse, con los comandos de tu distribución.
2. Lee su propio log, si lo guardas: la salida y el código de salida dicen si terminó bien.
3. Si no encuentras la línea CMD, comprueba que estés consultando el registro y el período correctos. Después, revisa por qué tu cron job no se ejecuta.

Entérate sin mirar los logs

Consultar los logs ayuda a investigar una ejecución. El monitoreo permite enterarte del problema sin tener que revisarlos cada día.