Cron logs: where to find them and how to check if a job ran

Cron’s logs let you check whether a command started, but they don’t always show whether it finished well. Here you’ll find where to read them on your system, and how to keep each job’s output and result.

Ubuntu and Debian

With rsyslog installed, cron writes to /var/log/syslog:

grep CRON /var/log/syslog
zgrep CRON /var/log/syslog*      # also the older, rotated files

Without rsyslog, as in Debian 12 and many minimal images, the log is in the systemd journal:

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

Each command cron starts leaves a line like this one (the date format depends on the system):

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

(root) is the user of the crontab, and CMD the command that cron started.

RHEL, CentOS, Fedora, Rocky and AlmaLinux

Cronie writes to /var/log/cron, and to the journal:

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

The jobs in /etc/cron.daily

The scripts in /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly don’t appear by name: the log shows the run-parts command that runs them all. On Debian and Ubuntu with anacron installed, the daily, weekly and monthly ones are run by anacron, and its log is separate:

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

To see which scripts run-parts would run, without running them:

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

In a Docker container

A container usually has no syslog, and the cron of Debian and Ubuntu images only logs there, so docker logs doesn’t show it (more in how to run cron jobs in a Docker container). You can:

• Send each job’s output to the container’s output, which docker logs does show. This line, with the user root after the schedule, goes in /etc/crontab or in a file of /etc/cron.d/:

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

• Use a cron that logs to the output, like BusyBox’s crond in Alpine images, or supercronic:

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

What the log doesn’t say

By default, a CMD line only means that cron started the command. It doesn’t say whether it finished, how long it took or which exit code it returned. To know that, keep each job’s output and exit code in a file:

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

Each run adds the date, everything the job printed, errors included, and its exit code: 0 if it went well. The line ends with the job’s own exit code, so whatever runs after it, or checks it, still sees whether the job failed.

Optional: log the end and the failures

On Debian and Ubuntu, cron can also log the end of each job and the ones that fail, with its -L option: the sum of 1 (start), 2 (end), 4 (failed, exit code other than 0) and 8 (process number). To log everything, run sudo systemctl edit cron, add these lines and restart cron with sudo systemctl restart cron:

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

Even then, the log doesn’t keep what the job printed: for that, keep its output as above.

How to check if a job ran

1. Look for its CMD line around the time it was due, with the commands for your distribution.
2. Read its own log, if you keep one: the output and the exit code tell whether it finished well.
3. If you don’t find the CMD line, check that you are reading the right log, and the right period. Then go through why your cron job isn’t running.

Know without looking at the logs

Reading the logs helps to investigate a run. Monitoring tells you about the problem without having to read them every day.