Where Are Cron Logs Stored?

On Debian and Ubuntu, cron logs to /var/log/syslog (filter with grep CRON /var/log/syslog). On RHEL, CentOS, Rocky and Fedora, it logs to /var/log/cron. On systemd systems you can also read journalctl -u cron or journalctl -u crond. These records show that a job started, not what it produced or whether it worked.

Key takeaways

• Debian and Ubuntu: /var/log/syslog. RHEL, Rocky and Fedora: /var/log/cron.
• The log proves cron ran the command. It records neither the output nor the exit code.
• Job output is emailed to the crontab owner, and on most servers that mail is discarded because no MTA is installed.
• Redirect output yourself with >> /var/log/job.log 2>&1, which captures errors as well as normal output.
• No log line at all means cron never tried, which is a different problem from a job that ran and failed.

Where to look, by system

Cron does not keep its own log file by default. It hands each event to the system logger under the cron facility, and where that ends up depends on the distribution.

On Debian and Ubuntu the cron entries are mixed in with everything else, so filter them out:

# Debian / Ubuntu
grep CRON /var/log/syslog | tail -50

# RHEL / Rocky / Fedora
sudo tail -50 /var/log/cron

# Any systemd system, following live
journalctl -u cron -f          # crond on RHEL-family

# Just today, for one user
journalctl -u cron --since today | grep myuser

A typical entry looks like CRON[12345]: (deploy) CMD (/usr/bin/php /var/www/app/task.php). It gives you the process id, the user the job ran as, and the exact command line cron executed.

What the log does not tell you

This is the part that wastes afternoons. That log line means cron started the command. It is not a record of what happened next.

• It does not record the exit code, so a script that failed immediately looks identical to one that succeeded.
• It does not record the output, so any error message the script printed is not there.
• It does not record how long the job took, or whether it ever finished.
• It records nothing at all if the job never started, which is precisely the case you most want to know about.

Where your job output actually goes

Cron collects anything a job writes to standard output or standard error and emails it to the user who owns the crontab. That behaviour dates from an era when every Unix machine ran a local mail system. Most servers no longer do, so the mail has nowhere to go and cron logs a line that surprises a lot of people the first time they see it:

(CRON) info (No MTA installed, discarding output)

That is not an error, and it is not something to fix by installing a mail server. It is cron telling you it had output to deliver and threw it away. Everything your script printed, including the stack trace explaining the failure, went into that void.

Capture the output yourself

Redirect it to a file you control. The important detail is 2>&1, which sends standard error to the same place as standard output. Without it you capture the successful chatter and lose the error message:

# Append output and errors to a log file
0 3 * * * /opt/app/backup.sh >> /var/log/backup.log 2>&1

# Same, with a timestamp on every run
0 3 * * * echo "--- $(date -Is)" >> /var/log/backup.log 2>&1; /opt/app/backup.sh >> /var/log/backup.log 2>&1

# Send it to syslog instead of a file, tagged so you can filter it
0 3 * * * /opt/app/backup.sh 2>&1 | logger -t backup

# Discard output entirely (only when you genuinely do not want it)
0 3 * * * /opt/app/backup.sh > /dev/null 2>&1

Getting the mail, if you want it

Setting MAILTO at the top of a crontab changes the destination address, and setting it to an empty string turns the mail off for every job below it. Both still depend on the machine having a working mail transfer agent, so on most modern servers redirecting to a file is the more reliable choice.

MAILTO=ops@example.com
0 3 * * * /opt/app/backup.sh

MAILTO=""
*/5 * * * * /opt/app/noisy-task.sh

Enabling a dedicated cron log on Ubuntu

If you would rather have cron entries in their own file than mixed into syslog, rsyslog can split them out. Uncomment the cron.* line in /etc/rsyslog.d/50-default.conf and restart the service:

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

# cron activity now also lands here
tail -f /var/log/cron.log

Add the new file to logrotate if you do this on a busy machine, otherwise it grows without limit.

When there is no log line at all

An empty log is information, not an absence of it. If you grep for your job and find nothing, cron never attempted it, which rules out the whole category of script problems and points at four things instead: the daemon is not running, the schedule does not match when you think it does, the job is in a different crontab from the one you are reading, or the crontab was never installed. The cron job not running checklist works through each in order.

Logs tell you what happened, after you think to look

Every technique here is retrospective. Redirecting output gives you something to read once you already suspect a problem, and that suspicion usually arrives late, because a job that has silently stopped generates no signal at all. Nothing appears in the log, no mail arrives, and the absence looks exactly like a quiet, successful night.

The fix is to make the job report in rather than waiting to read about it. With cron job monitoring the script pings a URL when it finishes, and a ping that does not arrive on schedule raises an alert. That catches the failures logging cannot: the job that hung, the daemon that stopped, and the crontab that disappeared during a server migration.

See how Pulsetic's cron job monitoring catches this from the outside, across 15+ locations.