Check Cron Job Status: Did It Actually Run and Succeed?

Do You Need to Check the Schedule or the Execution?

Two different questions hide behind "check cron job." One: is my crontab syntax correct and scheduled the way I think? If so, see Check Crontab Jobs: The Complete Verification Guide for verifying schedule expressions before anything runs.

The other question — the one this article answers — shows up mid-incident: the job was scheduled days ago, the time has passed, and now you need to know whether it ran, and whether it succeeded. That requires logs, exit codes, and process history instead of crontab syntax.

5 Ways to Check If a Cron Job Ran

Start with the simplest confirmation and work toward proof of success.

1. Confirm the job exists with crontab -l. Lists the current user's crontab entries so you can verify the command and schedule:

crontab -l

For another user's jobs, run sudo crontab -l -u username.

2. Search cron's own logs. Cron typically logs an entry every time it launches a job, even without saying anything about the result:

grep CRON /var/log/syslog

3. Query journalctl on systemd systems. Many modern distributions route cron activity through systemd's journal instead of a flat log file:

journalctl -u cron

or, on RHEL-based systems where the daemon is named differently:

journalctl -u crond

4. Check mail output. By default, cron emails stdout/stderr to the job owner's local mail account via mail or mailx:

mail

This only works if a mail transfer agent is installed — more on why that's a common dead end below.

5. Check your own redirected output and exit code. The only method that gives real proof of success, covered further down.

Together, these five checks answer "how to check cron jobs" from the outside in: does the job exist, did cron attempt it, and what happened when it ran.

Where Cron Logs Live (Ubuntu, RHEL, systemd)

Where cron logs are stored depends entirely on the distribution, which is why "check cron job logs" searches often lead to the wrong file:

• Ubuntu/Debian: /var/log/syslog — filter with grep CRON /var/log/syslog. Requires rsyslog to be configured to capture the cron facility.
• RHEL/CentOS/Fedora: /var/log/cron — a dedicated log file: grep /var/log/cron.
• systemd-only systems (no traditional syslog file): journalctl -u cron or journalctl -u crond. Add --since today to narrow results.

If none of these turn anything up, don't assume the job is broken — check the last section on missing log entries before troubleshooting further.

Checking Exit Codes and Actual Output

A log line proving cron launched a command tells you nothing about whether it finished successfully. To get that, redirect output and capture the exit code explicitly in your crontab entry:

* * * * * /path/to/script.sh >> /var/log/myjob.log 2>&1

This sends both standard output and errors to a file you control, so a failing command's error message lands somewhere readable. To capture the exit code, append a check inside the script or wrap the command:

/path/to/script.sh; echo "Exit code: $?" >> /var/log/myjob.log

An exit code of 0 means success; anything else signals failure, and the number often maps to a documented error condition. If commands could overlap (a long job still running when the next scheduled run fires), wrapping with flock prevents duplicate concurrent executions from corrupting output or double-processing data. If this check reveals the crontab entry itself is malformed — missing redirection, wrong shell, bad PATH — see Cron Job Command: Syntax, Crontab Flags & Silent Failures.

Why a Log Entry Doesn't Mean the Job Succeeded

This trap catches even experienced developers: cron's own logging records that it attempted the command, not that the command completed. /var/log/syslog, /var/log/cron, and journalctl entries confirm the scheduler fired at the right time — they say nothing about what the script did afterward. A script that crashes, times out, or exits with an error still produces a normal-looking "CRON... CMD" log line.

The mail fallback makes this worse. Cron's default behavior is to email command output to the local user account, but most servers — especially minimal cloud instances — don't have an MTA (mail transfer agent) like Postfix or Sendmail installed. Without one, that output is simply discarded: no log entry, no email, no indication anything went wrong. This is exactly how silent cron job failures happen: the job fails every night, cron logs a normal launch each time, and nobody notices until downstream data is visibly wrong.

If your exit-code check reveals the job runs but the script itself is unreliable — bad error handling, missing environment variables, unhandled edge cases — that's a script problem, not a cron problem. See Cron Job Script: How to Write One That Runs Correctly for writing scripts that fail loudly instead of silently.

Checking Cron Jobs Without Logging Into the Server

Every method above requires SSH access and a manual grep, which doesn't scale once you're running jobs across multiple servers or need to check status without SSH during an incident. Grepping five different log formats across five hosts, at 2 a.m., while a downstream system is already broken, is not a monitoring strategy.

The faster approach is heartbeat-style monitoring: your cron job sends a simple HTTP ping to a monitoring endpoint immediately after it finishes (a pattern popularized by tools like Healthchecks.io). If the ping doesn't arrive on schedule, the monitoring service knows the job failed to run or finish — without you checking anything manually.

Cronevra builds on that pattern with a single dashboard showing every scheduled job's last run, execution history, and success/failure state across every server, plus automatic alerts the moment a ping doesn't show up. Instead of SSHing in and grepping logs job by job, you get one status view and a notification before anyone downstream notices the failure. If you're managing more than a handful of cron jobs, Cronevra replaces the manual-log-checking routine above with monitoring that catches failures for you — check the pricing page to see what fits your setup.

Frequently Asked Questions

How do I check if a cron job actually ran?

Start with crontab -l to confirm the job is scheduled, then check the relevant log — /var/log/syslog on Ubuntu, /var/log/cron on RHEL, or journalctl -u cron/crond on systemd systems — for a launch entry. That confirms cron attempted the job; to confirm success, you need redirected output and an exit code check.

Where are cron job logs stored on Linux?

Location depends on distribution: Ubuntu and Debian use /var/log/syslog, RHEL and CentOS use a dedicated /var/log/cron file, and systemd-only systems route cron activity into the journal, viewable with journalctl -u cron or journalctl -u crond. If nothing appears, rsyslog may not be configured to capture the cron facility.

Why does my cron job log show it ran but nothing happened?

A cron log entry only confirms the scheduler launched the command, not that it finished successfully. The script may have crashed, errored, or hung after launch, and without redirected stdout/stderr or an exit code check, that failure leaves no trace in cron's own logs.

How do I check a cron job's exit code?

Add echo "Exit code: $?" immediately after your command in the crontab entry, redirecting output to a log file with >> /var/log/myjob.log 2>&1. A 0 means success; any nonzero value indicates the specific way the command failed.

Can I check cron jobs without SSH access to the server?

Yes, using heartbeat/HTTP-ping monitoring: the job pings a monitoring endpoint after each run, and a dashboard shows status without you ever logging into the server. Cronevra provides this as a single view across all your scheduled jobs, with automatic alerts when a ping is missed.

Why isn't my cron job showing up in /var/log/syslog?

Usually rsyslog isn't configured to capture the cron logging facility, more common on minimal or containerized Ubuntu installs. Check journalctl -u cron instead, since many modern systems route cron activity there even when /var/log/syslog shows nothing.