Crontab Log: Where to Find It and How to Read It

Run grep CRON /var/log/syslog on Ubuntu, cat /var/log/cron on RHEL/CentOS, or journalctl -u cron on a systemd-only box, and you'll usually have your crontab log on screen in under ten seconds. The rest of this walkthrough covers what to do when that command returns nothing, how to turn logging on, and where a log file — no matter how well configured — stops being enough.

What Counts as a "Crontab Log"

Crontab doesn't have a built-in log file of its own — there's no crontab.log sitting somewhere waiting to be opened. Does crontab log by default? Only indirectly: the cron daemon hands a message to your system logger (syslog or journald) every time it starts a job, and that logger writes the entry wherever it's configured to write.

So the crontab log meaning, practically speaking, is "the subset of your system log that mentions the cron process." That's why the location varies by distro, and why looking for a dedicated cron log file often ends in an empty search.

Where to Find Your Crontab Log, by System

The exact command depends on how your logging stack is set up.

Debian/Ubuntu (rsyslog):

grep CRON /var/log/syslog

or, for a live feed:

tail -f /var/log/syslog | grep CRON

RHEL/CentOS/Fedora: Cron entries get their own file by default.

tail -f /var/log/cron

Any systemd-based system (journalctl cron):

journalctl -u cron -f

or, on some distros, the unit is named crond:

journalctl -u crond -f

macOS:

log show --predicate 'process == "cron"' --last 1h

Alpine/BusyBox: Alpine's crond typically logs to /var/log/cron.log or straight to syslog if busybox syslogd is running — check both:

cat /var/log/cron.log

If none of these show anything, don't assume cron is broken — jump to the empty-log section below before troubleshooting the job itself.

Reading the Log Line Fast

Once you're looking at the right file, confirming you've found the correct entry takes one glance. A typical line looks like this:

Mar 3 02:15:01 web01 CRON[10432]: (deploy) CMD (/usr/bin/backup.sh)

That's a timestamp, hostname, the process name and PID (CRON[10432]), the user the job ran as (deploy), and the command executed. If you see this line appear at the moment your job was scheduled to run, cron fired the command. What it doesn't tell you is whether backup.sh actually finished successfully, which we'll get to shortly. For a full field-by-field breakdown of variations across distros, see Cron Log Explained: Location, Format, and Limits.

When the Log Is Empty: Enabling Cron Logging

A crontab log not showing entries usually comes down to one of three causes, in order of likelihood.

1. rsyslog isn't capturing the cron facility. Open /etc/rsyslog.d/50-default.conf (or /etc/rsyslog.conf on older systems) and check for a line like:

cron.*    /var/log/cron.log

If it's commented out with a #, remove the comment, save, and restart the service:

sudo systemctl restart rsyslog

This is the single most common fix — rsyslog cron facility logging is disabled by default on a surprising number of minimal server images.

2. The cron or rsyslog service itself isn't running. Confirm both:

systemctl status cron
systemctl status rsyslog

If either is inactive, start it and re-test.

3. You're checking the wrong log for your init system. On a machine running journald without rsyslog installed, /var/log/syslog may not exist at all — you need journalctl -u cron instead.

As a backup that doesn't depend on any of the above, redirect the job's own output directly in the crontab entry:

*/15 * * * * /usr/bin/backup.sh >> /var/log/backup-job.log 2>&1

This captures stdout and stderr regardless of what the system logger is doing, and it's often more useful anyway since it holds the script's actual output, not just a "job started" notice. If your logs point to environment or PATH issues in a PHP script specifically, this setup guide walks through the fix.

When Crontab Logs Aren't Enough

Even a perfectly configured log has a hard ceiling: it tells you cron invoked the command, not whether it succeeded, what it returned, or whether it ran within an acceptable time window. A script that hangs for six hours, exits with a silent error, or writes corrupted output produces the exact same "CMD" line as one that ran perfectly. That's the core of the cron log limitations — syslog and journald were built for auditing process activity, not tracking job outcomes.

Log rotation compounds the problem. Most systems rotate and eventually delete syslog entries after a week or two, so a failure from three weeks ago that's now causing downstream issues leaves no trail.

This is exactly the gap cron job monitoring tools are built for. Wrapping a scheduled job so it reports pass/fail status, captures full output, and triggers cron failure alerts when something goes wrong turns a blind log line into an actual signal you can act on. For broader practices around keeping scheduled jobs reliable in production, see Cron Jobs in Production: How to Keep Them Reliable.

If any of your cron jobs matter to the business — billing runs, backups, data syncs — don't rely on grepping syslog after the fact to find out something broke. Cronevra wraps your existing cron commands and gives you pass/fail status, output capture, and real alerts the moment a job fails or doesn't run at all.

Frequently Asked Questions

Why is my crontab log file empty even though the job is scheduled?

The most common cause is that rsyslog's cron facility line is commented out in /etc/rsyslog.d/50-default.conf, so entries never get written anywhere. Also check that both the cron and rsyslog services are running with systemctl status, and confirm you're checking the right log for your init system — journald-only systems won't populate /var/log/syslog at all.

Does crontab log by default, or do I have to turn it on?

Cron logging is typically enabled by default on most Linux distributions via syslog or journald, but it depends on the distro image and whether rsyslog's cron facility is active. Minimal or containerized images often ship with cron logging disabled, requiring you to uncomment the relevant rsyslog config line and restart the service.

How do I see cron logs on a system that only uses journalctl?

Run journalctl -u cron -f or journalctl -u crond -f, depending on how your distro names the cron unit. This streams entries live as jobs fire, the systemd equivalent of tailing /var/log/syslog or /var/log/cron.

What's the difference between the crontab file and the crontab log?

The crontab file (edited with crontab -e) defines what jobs run and when — it's your schedule. The crontab log is a record, written by the system logger, confirming that cron actually triggered those jobs; the two serve different purposes and live in different places.

Can I make cron write to my own custom log file instead of syslog?

Yes — redirect output directly in the crontab entry, for example * * * * * /path/script.sh >> /var/log/my-job.log 2>&1. This captures the script's own stdout and stderr independent of the system logger, more reliable if rsyslog isn't configured for cron.

Why does my cron log show the job ran but not whether it succeeded?

Because syslog and journald only record that cron invoked the command, not its exit code, output, or runtime. A script that fails silently or hangs produces the same log line as one that finishes cleanly, which is why teams running anything critical add pass/fail tracking and alerts with a tool like Cronevra instead of relying on raw logs alone.