Where Are Cron Logs Stored? How to Check Cron Job Logs (Ubuntu, CentOS)

Cron logs that a job ran to the system log, but the file differs by distro. On Ubuntu and Debian, cron writes to /var/log/syslog (filter with grep CRON). On RHEL, CentOS, Rocky, AlmaLinux, and Fedora, cron writes to a dedicated file at /var/log/cron. Importantly, the output of a cron job (its stdout/stderr) is not in these files — it's emailed via MAILTO or discarded unless you redirect it yourself.

Quick Reference: Cron Log File Paths

On systemd distros, cron activity is also captured by the journal regardless of distro — see the journalctl commands below.

How to View and Tail Cron Logs

Ubuntu / Debian (cron logs into syslog):

# All cron activity, live
sudo grep CRON /var/log/syslog
sudo tail -f /var/log/syslog | grep CRON

# Just a specific script
sudo grep "backup.sh" /var/log/syslog

RHEL / CentOS (dedicated file):

sudo tail -f /var/log/cron
sudo grep CROND /var/log/cron
sudo grep "(root)" /var/log/cron     # jobs run as root

Any systemd distro (via the journal):

journalctl -u cron        # Debian/Ubuntu unit name
journalctl -u crond       # RHEL/CentOS unit name
journalctl -t CRON        # filter by syslog identifier
journalctl -u cron --since "1 hour ago"

A typical execution line looks like:

Jun  1 09:00:01 host CRON[2451]: (root) CMD (/usr/local/bin/backup.sh)

That confirms the job started. It does not tell you whether the script succeeded.

Capturing a Job's Actual Output

Because cron only logs execution, you must redirect output yourself to see what a job did. In the crontab line:

# stdout + stderr to a dedicated log
0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

# stderr only (silence normal output, keep errors)
0 2 * * * /usr/local/bin/backup.sh > /dev/null 2>> /var/log/backup-errors.log

2>&1 must come after the >> so stderr is redirected to the same place as stdout.

Email instead of files

If you set MAILTO at the top of the crontab, cron emails any output the job produces:

MAILTO="[email protected]"
0 2 * * * /usr/local/bin/backup.sh

This requires a working local MTA (postfix/sendmail). With no mail configured, the output is silently dropped — a common reason people think a job "produced nothing." Set MAILTO="" to explicitly disable mail.

Where Cron Logging Is Configured

Cron's execution logging is produced by rsyslog using the cron facility. The rule lives in:

• Debian/Ubuntu: /etc/rsyslog.d/50-default.conf — there's a commented line #cron.* /var/log/cron.log. Uncomment it and restart rsyslog to get a dedicated file:

  sudo sed -i 's/^#cron\./cron./' /etc/rsyslog.d/50-default.conf
  sudo systemctl restart rsyslog
  

  Copy

• RHEL/CentOS: /etc/rsyslog.conf already contains cron.* /var/log/cron, which is why the dedicated file exists out of the box.

To raise cron's own verbosity, the daemon accepts a -L log-level flag (e.g. -L 2 to also log when jobs start); set it in /etc/default/cron (Debian) or the crond options.

Log Rotation

Cron logs are rotated by logrotate:

• On Debian/Ubuntu, cron rides along with the syslog rotation in /etc/logrotate.d/rsyslog.
• On RHEL/CentOS, /var/log/cron is listed in /etc/logrotate.d/syslog.

Rotated files become cron.1, cron.2.gz, etc. Read compressed rotations with zgrep:

sudo zgrep CRON /var/log/syslog.*.gz       # Ubuntu
sudo zgrep CROND /var/log/cron-*.gz        # RHEL (dated rotations)

Force rotation to test the rule:

sudo logrotate -f /etc/logrotate.d/syslog

Common Errors You'll Find in Cron Logs

• (root) CMD (/path/script.sh) — normal: the job started. No CMD line means it never ran.
• (CRON) error (grandchild #NNNN failed with exit status 1) — the job ran but exited non-zero; check the script's own redirected log for the real error.
• (user) CANNOT EXECUTE (Permission denied) — the script isn't executable or the path is wrong; chmod +x it and use absolute paths.
• (root) MAIL (mailed N bytes of output but got status 0x004b) — cron tried to email output but the MTA failed; install/fix postfix or set MAILTO="".
• (*system*) RELOAD (/etc/cron.d/myjob) — cron noticed and reloaded a crontab file; confirms your edit was picked up.
• pam_unix(crond:session): session opened for user root — appears in auth logs when crond starts a job; useful to correlate cron activity with PAM.

Troubleshooting: Logs Missing or Empty

• No CRON lines anywhere — The cron daemon isn't running. Check systemctl status cron (Debian) or systemctl status crond (RHEL) and start/enable it.
• /var/log/cron doesn't exist on Ubuntu — Expected; Ubuntu logs cron to /var/log/syslog. Either grep syslog or enable the dedicated file as shown above.
• Job shows in the log but "did nothing" — The job ran; its output went to email (no MTA = dropped) or to a place you didn't check. Redirect output to a file with >> /var/log/myjob.log 2>&1.
• Job runs by hand but not from cron — Almost always environment/PATH. Cron runs with a minimal environment; use absolute paths to binaries and set any required variables inside the script or crontab.
• Per-user crontab edits don't take effect — Confirm you edited the right user's crontab (crontab -e -u <user>) and that cron.allow/cron.deny don't block that user.
• Logs are root-readable only — /var/log/syslog and /var/log/cron need sudo; add yourself to the adm group on Debian/Ubuntu to read without it.