Cron Job Logs: Where to Find Them and What They Miss

Ask ten developers where cron job logs live and you'll get five confident answers, three shrugs, and two people who just SSH in and grep around. That's not because cron logging is complicated — it's because it isn't centralized, isn't consistent across systems, and isn't a proper application log to begin with. It's a byproduct of your system logger, and the cron daemon writes to it as an afterthought.

This piece covers the lookup fast, then spends the real time on what a cron log entry actually tells you, and — more importantly — what it structurally cannot. That gap is the reason "the cron job ran fine" and "the cron job worked" are two very different claims.

What Counts as a "Cron Job Log" (and Where It Lives)

There's no dedicated cron.log file baked into Linux by default. Instead, the cron daemon (cron or crond, depending on distro) reports each job invocation to your system's logging facility — either the classic syslog stack (rsyslog/syslog-ng) or, on modern distros, the systemd journal. Cron job logs are really just cron-tagged entries sitting inside a much bigger, general-purpose log stream.

That means the cron log location depends entirely on how your OS handles logging, not on cron itself. A Debian-based server, a RHEL box, and a systemd-only container image can each store the same information in a completely different place — or not persist it at all.

Finding Cron Logs by System

Here's the reference, distro by distro:

System	Where to look	Command
Ubuntu / Debian	/var/log/syslog	grep CRON /var/log/syslog
RHEL / CentOS / Fedora	/var/log/cron	tail -f /var/log/cron
systemd-based (any distro)	journal, unit cron or crond	journalctl -u cron or journalctl -u crond
Minimal/container images	often nothing at all	check if cron/rsyslog is even installed

On Ubuntu and Debian, cron logs are folded into the general syslog file, so you filter with grep. On CentOS and RHEL, cron gets its own file — /var/log/cron — easier to tail directly. If your distro runs systemd (most current ones do), journalctl queries work regardless of whether rsyslog also writes a flat file, making it the most portable lookup method across a mixed fleet.

Slim container images and minimal cloud instances are the case people miss: many don't ship rsyslog or a persistent journal at all, so there's no log to find until you install and configure one yourself.

If you also need to double check what's actually scheduled to run — not just what already logged — see this reference on viewing crontab jobs in every scenario.

Why Your Cron Log Is Empty or Missing

When cron logs aren't showing up, the cause is almost always one of four things:

• rsyslog isn't installed or isn't configured to capture cron. Some minimal distros ship without rsyslog, or ship it with the cron facility commented out in /etc/rsyslog.d/50-default.conf. Check with dpkg -l | grep rsyslog (Debian/Ubuntu) or rpm -q rsyslog (RHEL-family).
• The journal is non-persistent. By default, some systems keep journalctl logs only in memory, wiping them on reboot. Run journalctl --list-boots to see if history predates the current boot; if not, persistent storage isn't enabled.
• The cron daemon isn't actually running. systemctl status cron (Debian-based) or systemctl status crond (RHEL-based) confirms this in seconds — a stopped daemon produces zero log lines and zero executions.
• Logging is deliberately quiet. Older /etc/crontab setups and some cron builds support a -L verbosity flag or a "no logging" default; check your cron package's config for logging level.

A cron log missing entirely is a configuration issue, not a cron mystery — it just requires checking the logging layer, not the scheduler itself.

Reading a Cron Log Line: What's Actually In It

A typical CRON log entry from syslog looks like this:

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

Breaking down the cron log format: you get a timestamp, hostname, the CRON tag with a process ID, the user the job ran as, and the exact command that was invoked. That's genuinely useful for confirming when something fired and as whom — often the first stop when a scheduled task seems to have gone missing.

Notice what's conspicuously absent from that line: anything about what backup.sh actually did once it started.

The Blind Spot: What Cron Logs Never Tell You

This is the part most references skip. A cron log entry only confirms that the daemon handed a command off to the shell — it says nothing about what happened next. There's no exit code, no captured stdout or stderr, no duration, no success/failure flag. The log line above is written the instant the command starts, regardless of whether it finishes in two seconds or hangs for two hours, and regardless of whether it exits 0 or 1.

That's how a cron job failing silently becomes such a common story. The script errors out, the log still shows a clean CMD entry, and everything looks fine — because as far as cron is concerned, it did its job the moment the process launched. Output logging isn't part of the deal unless you explicitly build it yourself.

Capturing Real Output (Without Relying on Mail)

The fastest fix is redirecting cron output directly in the crontab line:

0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

That 2>&1 sends stderr to the same place as stdout, so both land in your log file instead of vanishing or, historically, getting emailed via MAILTO. That mail-based approach is unreliable enough — dependent on a working local MTA, often silently dropped — that it's not a dependable safety net.

To actually capture the exit code, wrap the command and log $? explicitly, or pipe the whole thing into a script that records status alongside output. Either way, you now have a record of what happened, not just what was attempted.

When Logs Aren't Enough: Closing the Gap

Even with output redirection in place, someone still has to read the file. Cron job monitoring exists precisely because logs are passive — they wait for you to look, and most failures get discovered when a downstream process breaks, not when the log was written. Cron failure alerts flip that model: instead of grepping a file after something's already gone wrong, a monitor pings you the moment a job doesn't check in on schedule or reports a non-zero exit.

Cronevra does exactly that — it sits on top of your scheduled HTTP jobs and tracks execution history, failures, and recovery automatically, so nothing depends on someone remembering to tail a log. If you're ready to see what that looks like for your setup, Cronevra's pricing page has the plans.

Closing: Necessary, Not Sufficient

Cron logs confirm the daemon fired — they were never built to confirm the job succeeded, and no amount of grepping changes that. Once you've found the log line proving cron attempted the task, the real question — did it actually work, and will you know the next time it doesn't — is one log files can't structurally answer. That's the gap monitoring closes. Take a look at Cronevra if you'd rather find out about failures from an alert than from a downstream outage.

Frequently Asked Questions

Where are cron logs stored on Ubuntu vs CentOS?

Ubuntu and other Debian-based systems fold cron entries into /var/log/syslog, so you filter them with grep CRON /var/log/syslog. CentOS, RHEL, and Fedora write cron activity to its own dedicated file, /var/log/cron, which you can tail directly without filtering.

Why is my /var/log/cron file empty or not showing up?

The most common causes are rsyslog not being installed or configured to capture the cron facility, the cron daemon not running, or logging set to a quiet mode. Check systemctl status crond and confirm rsyslog is installed and active before assuming cron itself is broken.

How do I see cron logs with journalctl?

Run journalctl -u cron on Debian-based systems or journalctl -u crond on RHEL-based ones to query the systemd journal directly. This works even where a flat log file isn't configured, making it the most portable method across mixed environments.

Does a cron log entry mean the job succeeded?

No — a cron log entry only confirms the daemon launched the command, not that it completed successfully. There's no exit code, output, or duration recorded, so a script that fails immediately after starting still produces a normal-looking log line.

How do I capture a cron job's output and exit code?

Redirect both stdout and stderr in the crontab line itself, for example >> /var/log/job.log 2>&1, and log $? if you need the explicit exit code. This is more reliable than depending on MAILTO, which requires a working local mail setup and often fails silently.

Do logs disappear after a server reboot?

They can, if your system's journal is configured as non-persistent (memory-only), which is the default on some distros. Run journalctl --list-boots to check whether history survives past the current boot, and enable persistent storage in journald's configuration if it doesn't.