Cron Logs in Linux: Where to Find Them by Distro

Cron logs in Linux don't live in one universal place — the correct file or command depends on your distro and init system, which is why so many "grep cron" searches come up empty. If you're mid-incident, skip to the table below, find your distro, and copy the command. Then we'll cover what actually trips people up: missing log files, log rotation eating your history, and the gap between "cron ran it" and "the job worked."

Where Cron Logs Live, By Distro

The cron log location splits along one main line: Debian-family distros route cron activity through rsyslog into a general system log, while Red Hat–family distros give cron its own dedicated file.

• Ubuntu / Debian: /var/log/syslog — cron entries are mixed in with everything else, so filter with grep CRON /var/log/syslog.
• RHEL / CentOS / Fedora / Rocky / AlmaLinux: /var/log/cron — a dedicated file, viewable directly with tail -f /var/log/cron.
• Arch Linux / systemd-only systems: no plaintext file by default — everything lives in the journal, accessed via journalctl.
• Alpine Linux (busybox cron): logs typically go to /var/log/cron.log if crond is started with logging enabled, or straight to syslog otherwise.

If grep CRON /var/log/syslog returns nothing on Ubuntu, don't assume cron is broken — check whether you're on a systemd journal-only setup, or whether dedicated logging was never enabled (both covered below).

Reading Cron Logs with journalctl (systemd Systems)

On any modern systemd-based distro, journalctl is the most reliable way to read cron logs regardless of whether a flat file also exists, since journald captures the same events at the source. The catch is that the unit name varies by distro, since the cron daemon goes by different names depending on which package built it.

Try these in order until one returns output:

journalctl -u cron
journalctl -u crond
journalctl -u cronie

• Ubuntu/Debian: unit is usually cron
• RHEL/CentOS/Fedora: unit is crond
• Arch and some minimal distros: the package is cronie, and the unit may be cronie or crond depending on how it was installed

Once you've got the right unit, narrow the results:

journalctl -u cron --since today
journalctl -u cron -f
journalctl -u cron --since "1 hour ago"

--since today answers "did anything run this morning?" without scrolling through days of output, and -f follows the log live. To isolate a specific user's jobs, pipe into grep: journalctl -u cron | grep username.

Enabling a Dedicated cron.log (When It's Missing)

If you're on Ubuntu or Debian and expected a /var/log/cron.log file, here's why it's missing: dedicated cron logging is disabled by default and folded into /var/log/syslog instead. This is the most common reason developers think their cron logs "disappeared" — they were never split out to begin with.

To enable it, edit rsyslog's cron config:

sudo nano /etc/rsyslog.d/50-default.conf

Find the line:

#cron.*    /var/log/cron.log

Uncomment it by removing the #, save the file, then restart rsyslog:

sudo systemctl restart rsyslog

New cron activity will now write to /var/log/cron.log going forward — this won't retroactively populate history, so trigger a test job to confirm it's working:

tail -f /var/log/cron.log

If the file still stays empty after a manual run-parts or a scheduled job fires, verify rsyslog is running (systemctl status rsyslog) and that no other rule intercepts cron.* earlier in the config.

Reading a Log Line: What CRON[PID] Actually Tells You

A typical cron log entry looks like this:

Jun 12 03:00:01 web01 CRON[24816]: (deploy) CMD (/usr/local/bin/backup.sh)

Breaking it down: the timestamp is when cron invoked the job, CRON[24816] is the process ID assigned to that execution, (deploy) is the system user the job ran as, and CMD (...) is the exact command cron executed. This confirms cron fired the job on schedule — it does not tell you whether backup.sh exited cleanly, timed out, or failed halfway through. That distinction between execution and success is the core limitation of relying on logs alone, worth understanding further in Cron Job Logs: Where to Find Them and What They Miss. If you see no CRON line at all for a job you expect to run, it may not be scheduled the way you think — worth checking against View Crontab Jobs in Linux: Every Scenario, Explained.

Log Rotation: Why Old Cron History Disappears

Both /var/log/syslog and /var/log/cron are managed by logrotate, which rotates, compresses, and eventually deletes old log files on a schedule defined in /etc/logrotate.d/rsyslog or /etc/logrotate.d/cron. That's why a failure from ten days ago seems to vanish — it's likely sitting compressed as syslog.2.gz or cron-20240601.gz rather than gone entirely.

To search rotated, compressed logs without manually decompressing each one:

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

Default retention is usually 4–7 rotations depending on distro defaults, often translating to just one to a few weeks of searchable history — not enough if you're trying to spot a pattern of intermittent failures over a month.

When Logs Aren't Enough

Grepping syslog or running journalctl works fine when you already know something went wrong and you're willing to dig for it after the fact. It doesn't work when a job silently fails at 3 a.m. and nobody checks the log until a downstream system breaks days later — reading logs is inherently reactive, and it depends on you remembering to look. Real cron job monitoring flips that: instead of you querying logs for failures, the system pings you the moment a scheduled job doesn't run, doesn't finish, or doesn't check in on time.

Once you've confirmed via logs that cron actually ran (or didn't), the practical next step is deciding whether you want to keep doing this manually every time something feels off. Cronevra turns that grep-and-hope routine into automatic cron failure alerts, so you find out about a broken job from a notification instead of from a customer. If you're ready to see what that looks like for your setup, check Cronevra's pricing.

Frequently Asked Questions

Why don't I have a /var/log/cron.log file on my Ubuntu server?

Dedicated cron logging isn't enabled by default on Debian and Ubuntu — cron activity is written into /var/log/syslog instead, filtered under the cron facility. You can enable a separate cron.log file by uncommenting the relevant line in /etc/rsyslog.d/50-default.conf and restarting rsyslog.

What's the difference between /var/log/syslog and /var/log/cron?

/var/log/syslog is a general system log used by Debian/Ubuntu that contains cron entries mixed with other services, while /var/log/cron is a dedicated file used by RHEL, CentOS, and Fedora that contains only cron-related activity. Functionally they capture the same type of information — cron just isn't isolated on Debian-based systems unless you configure it.

How do I see only today's cron activity in journalctl?

Run journalctl -u cron --since today (swap cron for crond or cronie depending on your distro's unit name). This filters the journal to entries logged since midnight, avoiding the need to scroll through older history.

Do cron logs show whether my job actually succeeded?

No — a cron log entry only confirms that cron invoked the command at the scheduled time, shown by the CMD (...) portion of the log line. It does not capture the script's exit code, error output, or whether the underlying task completed successfully.

Why is my cron service called crond on some servers and cron on others?

The naming depends on which cron implementation your distro ships: Debian and Ubuntu typically use a package named cron, while RHEL, CentOS, and Fedora use cronie, whose service is registered as crond. That's why journalctl unit names differ, and why it's worth trying cron, crond, and cronie in sequence when you're unsure.

How far back do cron logs typically go before they're rotated away?

It depends on your logrotate configuration, but most distro defaults keep somewhere between 4 and 7 rotated files, often amounting to just one to a few weeks of history. Older entries are compressed into files like syslog.3.gz, searchable with zgrep, before eventually being deleted entirely.