Crontab Log

Luke Hebert

- 2 minutes read - 271 words

When a scheduled job silently fails to run, the cron log is the first place to look. Knowing where those logs live and what they tell you saves a lot of guesswork.

Where Cron Logs Live

The location depends on your distribution:

  • RHEL, CentOS, Rocky Linux: /var/log/cron
  • Debian, Ubuntu: /var/log/syslog (filter for CRON)
  • SUSE: /var/log/cron

On systems using systemd-journald, you can also query with:

journalctl -u cron

Reading a Cron Log Entry

A typical line looks like this:

Jan 24 03:00:01 myhost CRON[12345]: (root) CMD (/usr/local/bin/backup.sh)

The fields break down as:

  • Date and time the job fired
  • Hostname
  • CRON[pid] - the cron daemon process ID
  • (user) - which user’s crontab the job belongs to
  • CMD - the exact command that was executed

Quick Checks

List the current user’s crontab entries:

crontab -l

Tail the cron log in real time while you wait for a job to fire:

tail -f /var/log/cron

Filter for a specific user:

grep "myuser" /var/log/cron

Common Pitfalls

Note

If you see no log entry at all for a scheduled job, the issue is usually one of three things: the cron daemon is not running, the crontab file has a syntax error, or the job’s PATH does not include the directory where the script lives.

Important

Cron does not inherit your shell environment. Always use absolute paths in crontab entries, or source your profile explicitly at the top of the script.

Verifying the Daemon Is Running

systemctl status cron

or on RHEL-based systems:

systemctl status crond

If the service is stopped, start it and confirm the log file begins receiving new entries.