Check Cron Logs: Commands, Filters & Real-Time Views

The Fastest Way to Check Cron Logs Right Now

If you just need to check cron logs this second, run one of these two commands.

On a syslog-based system (Ubuntu/Debian):

grep CRON /var/log/syslog

On a systemd-based system, use journalctl instead:

journalctl -u cron --since today

Either command dumps every cron invocation the scheduler has logged, newest at the bottom. If the first returns nothing, your distro likely routes logging through systemd's journal rather than a flat file — that's what the second command is for. This confirms whether the scheduler woke up and tried to run your job at all. It won't tell you whether the job actually did what it was supposed to, but that's a problem for later in this article.

Checking Logs by System Type

Cron logging isn't standardized across distros, so the command that works on your laptop may return nothing on a production server. Three branches cover almost every case.

Syslog-based systems (Debian, Ubuntu, older distros):

grep CRON /var/log/syslog

RHEL, CentOS, Fedora, Amazon Linux (dedicated cron log):

grep CRON /var/log/cron

Systemd journal (modern distros, containers, minimal installs):

journalctl -u cron        # Debian/Ubuntu naming
journalctl -u crond       # RHEL/CentOS naming
journalctl -u cronie      # some Arch/openSUSE setups

The unit name varies by distro because cron is packaged and named differently — if one doesn't resolve, list active units with systemctl list-units | grep -i cron to find the right one.

macOS doesn't log cron activity to a flat file by default. Use the unified logging system instead:

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

For the exhaustive, distro-by-distro file path breakdown — including edge cases like syslog-ng, rsyslog config overrides, or containers with no init system — see Cron Logs in Linux: Where to Find Them by Distro.

Filtering and Searching for the Job You Care About

Once you can see cron log output, the real question is usually narrower: did this specific job run, and did it throw an error?

Filter by job name or script path:

grep CRON /var/log/syslog | grep backup.sh
journalctl -u cron | grep backup.sh

Filter by a date/time window:

journalctl -u cron --since "2024-01-15 00:00" --until "2024-01-15 23:59"

Watch logs in real time — essential when you're waiting on a job that's about to fire:

tail -f /var/log/syslog | grep CRON
journalctl -u cron -f

Search for failure keywords:

grep -iE "error|fail|denied" /var/log/cron

Search rotated or compressed logs (syslog rotates daily/weekly and gzips old files):

zgrep CRON /var/log/syslog.*.gz

If a job that's clearly scheduled produces no matching lines at all, that's usually not a logging bug — it typically means a permissions issue, a missing crontab entry for that user, or a syslog facility not configured to capture cron events. Check crontab -l for the correct user first, since cron jobs run under the crontab of the user who owns them, and root's crontab is separate from a regular user's.

Reading the Output: What CRON Log Lines Actually Tell You

A typical line looks like this:

Jan 15 03:00:01 web01 CRON[24817]: (deploy) CMD (/opt/scripts/backup.sh)

Breaking it down: Jan 15 03:00:01 is the timestamp the scheduler fired the job, web01 is the hostname, CRON[24817] is the process and PID, (deploy) is the user the job runs as, and CMD (...) is the exact command executed.

Here's the part that trips people up: this line only proves cron invoked the command. It says nothing about what happened next. The script could have exited with a non-zero status, thrown an unhandled exception, hung indefinitely, or silently written nothing where output was expected — and the log line above would look identical either way. Cron logs the launch, not the outcome. Cron only captures stdout/stderr if your crontab is configured to redirect it somewhere, or if mail delivery is set up — by default, output often just disappears.

This is precisely why checking cron logs answers "did it fire?" but almost never answers "did it work?"

When Checking Logs Isn't Enough

Grepping through logs works fine for one job on one server when something's already gone wrong and you're debugging after the fact. It stops working the moment you have more than a handful of jobs, more than one server, or a business requirement that failures get caught before a customer notices.

Manual log-checking is reactive by nature — you have to know to look, and you have to look after the damage is done. It's also blind to things that matter operationally: exit codes, run duration, whether a job silently stopped running weeks ago, and whether a job on server B failed while the identical job on server A succeeded. None of that surfaces in a grep CRON output. A job that hangs forever, or one that exits 1 but still prints a normal-looking log line, produces exactly the kind of silent failure that logs alone will never flag. For a deeper breakdown of what log files miss, see Cron Job Logs: Where to Find Them and What They Miss.

Real cron job monitoring flips the workflow: instead of you checking logs, the system checks in on your jobs and tells you the moment one fails, runs late, or doesn't run at all — across every server, not just the one you happened to SSH into.

grep and journalctl will tell you a job fired. They won't tell you it succeeded, and they definitely won't tell you it ran on schedule across ten servers at 3 a.m. when nobody was watching. Cronevra closes that gap with instant alerts on failures and missed runs, so you find out from a notification instead of an angry customer. Check the pricing page to see plans built for teams running scheduled jobs at any scale.

Frequently Asked Questions

Why doesn't my cron log show any output at all?

Most often it's because the crontab entry belongs to a different user than the one you're checking, cron's syslog facility isn't configured to capture events, or the job's stdout/stderr was never redirected anywhere. Run crontab -l -u to confirm the job exists under that user, and check that your syslog or journal service is running.

What's the difference between grep CRON /var/log/syslog and journalctl -u cron?

grep CRON /var/log/syslog searches a flat text log file used by traditional syslog-based systems like Debian and Ubuntu. journalctl -u cron queries the systemd journal, a structured binary log used by most modern Linux distributions — use whichever matches how your system logs, since only one will typically return results.

How do I check cron logs for a job that ran yesterday?

Use a time-bounded journalctl query like journalctl -u cron --since yesterday --until today, or grep a syslog file with a date filter if it hasn't rotated yet. If the log has rotated and compressed, use zgrep CRON /var/log/syslog.1.gz or similar to search the archived file.

Can I check cron logs on macOS the same way as Linux?

No, macOS doesn't maintain a plain-text cron log file by default like Linux syslog does. Instead, use the unified logging system with log show --predicate 'process == "cron"' --last 1h to view recent cron activity.

How do I know if a cron job failed versus just didn't run?

A log entry showing CMD (...) means cron fired the job, but a failure inside the script won't change that line — you'd need the script to log its own exit status or output somewhere you check separately. If there's no log entry at all for the expected time, the job likely didn't run, which usually points to a crontab misconfiguration or a scheduler issue rather than a script bug.

Do I need sudo to check cron logs?

Usually yes, since files like /var/log/syslog and /var/log/cron are typically readable only by root or users in a privileged group. journalctl -u cron may also require sudo depending on your system's journal permissions, though some distros allow members of the adm or systemd-journal group to read it without elevation.