Check Crontab Jobs: The Complete Verification Guide

Why "Is My Cron Job Running?" Is Harder Than It Sounds

Cron runs quietly in the background, which makes it frustrating to debug. There's no dashboard, no built-in success email unless you configure one, and no consistent place to look for evidence — Ubuntu, RHEL, and minimal cloud images all store their trail of proof differently. Most developers default to grepping random log files and hoping something useful turns up.

A more reliable approach is a three-step path: confirm the job is actually scheduled, confirm the cron daemon is running, and confirm — via logs — that the job executed. Each step rules out a different failure mode, and working through them in order saves you from chasing the wrong problem. This guide walks through each step with exact commands, then explains why even a perfect log-checking routine still leaves a blind spot.

Step 1: Confirm the Job Is Actually Scheduled

Before assuming a job is broken, verify it's actually registered. Run crontab -l to list cron jobs for your current user — this prints every scheduled entry exactly as cron sees it, including typos in the schedule syntax that might explain unexpected behavior.

Troubleshooting a job owned by another account requires elevated privileges: sudo crontab -u username -l shows that user's crontab. This is essential in team environments where deploy scripts or service accounts own the schedule instead of a person.

Don't stop at per-user crontabs, though. System-wide jobs often live outside any individual user's file — check /etc/crontab and the contents of /etc/cron.d/, where packages and provisioning scripts frequently drop their own schedule files. A job that "doesn't exist" in crontab -l might simply be defined at the system level instead. If the schedule line itself looks malformed, the syntax reference in Cron Job Command: Syntax, Crontab Flags & Silent Failures breaks down field-by-field formatting and common flag mistakes.

Step 2: Confirm the Cron Daemon Is Running

A perfectly valid crontab entry is worthless if the daemon isn't running. Check with systemctl status cron on Debian-based systems, or systemctl status crond on RHEL-based ones — the service name varies because different distros ship different cron implementations, typically Vixie cron on Debian/Ubuntu and cronie on RHEL, CentOS, and AlmaLinux.

Run this sanity check before digging into logs. If the service comes back inactive or failed, no amount of log-grepping will explain the missing job — the fix is restarting the service, not debugging the script.

Step 3: Check the Logs to See If the Job Actually Ran

Once you know the job is scheduled and the daemon is alive, logs tell you whether cron actually attempted execution at the expected time. Where those logs live depends entirely on your distro.

Ubuntu / Debian: /var/log/syslog

Run grep CRON /var/log/syslog to pull every cron-related line. Look for CMD entries — each one marks a specific command cron attempted to run, along with the timestamp and user. If you see the CMD line at the right time, cron did its job; whether your script succeeded is addressed in Step 4.

RHEL / CentOS / AlmaLinux: /var/log/cron

The equivalent command here is grep CRON /var/log/cron (or simply cat /var/log/cron on quieter systems). Cronie, the cron implementation used on these distros, sometimes adds CMDOUT lines capturing command output directly in the log, which can save a debugging step if output logging is enabled.

Systemd Systems: journalctl -u cron (or crond)

On systemd-managed systems — especially minimal or cloud images that don't ship rsyslog by default — traditional log files may not exist at all. Here, journalctl -u cron --since "24 hours ago" | grep CMD (swap in crond depending on your distro) is often the only way to confirm execution. This is frequently the missing piece on trimmed-down Docker or VPS images where nothing is writing to /var/log.

Step 4: Capture Your Own Job Output for Real Answers

Here's the catch: system logs confirm that cron attempted the job — not that it succeeded. A CMD entry just means cron launched the command; it says nothing about exit codes, errors, or whether the script did what it was supposed to do.

To get real answers, redirect the job's own output to a file. Appending >> /var/log/myjob.log 2>&1 to the end of your crontab command captures both standard output and standard error in one place, so you can inspect exactly what the script printed and whether it exited cleanly. This small addition turns "cron said it ran" into "here's what actually happened." If the log reveals a bug in the script itself rather than a scheduling issue, Cron Job Script: How to Write One That Runs Correctly covers common script-level pitfalls.

Common Reasons a Job Looks Fine in Logs but Still Fails

A CMD entry with no obvious errors doesn't guarantee success. The most common silent-failure causes:

• Missing environment variables — cron runs with a minimal environment, so anything relying on variables set in your .bashrc or shell profile simply won't exist.
• Relative file paths — a script that works from your home directory may fail under cron because the working directory is different or undefined.
• Permissions — the user cron runs as may lack access to files, directories, or executables the script depends on.
• Mail delivery being disabled — cron traditionally emails output via MAILTO, but on servers without an MTA (Mail Transfer Agent) configured, that mail silently vanishes instead of erroring out.

These are the classic explanations behind "it works when I run it manually but not under cron" — the environment, not the schedule, is usually the culprit.

Why Log-Checking Isn't Enough — and What to Do Instead

Even with every command above memorized, manual log-checking has a structural flaw: it requires you to remember to look. It doesn't alert you the moment a job fails or silently stops running, and it falls apart entirely if you lose SSH access, the server goes down, or the log itself gets rotated out by logrotate before you get to it.

This is the gap a cron job monitoring tool is built to close. Cronevra works by having your job send an HTTP ping on completion — no log access, no SSH session, no daemon status checks required. Cronevra tracks execution history automatically and sends cron job alerts the moment a run fails or simply never checks in, so you find out in real time instead of during your next manual audit.

If you're still setting up your first scheduled task, Setting Up a Cron Job: The Complete Beginner's Guide walks through the basics before you get to this verification stage. And if you're ready to stop grepping logs altogether, Cronevra's pricing shows how quickly monitoring pays for itself the first time it catches a failure you would have otherwise missed.

Frequently Asked Questions

How do I check what cron jobs are scheduled for another user?

Run sudo crontab -u username -l, replacing "username" with the target account. This requires sudo privileges and prints that user's full crontab exactly as cron reads it — the standard way to audit scheduled jobs owned by service accounts or teammates.

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

They're distro-specific log locations for the same underlying purpose. /var/log/syslog is used on Ubuntu and Debian systems, while /var/log/cron is the RHEL, CentOS, and AlmaLinux equivalent — both record cron's attempts to launch scheduled commands, just under different filenames.

How do I know if my cron job actually ran today?

Check the relevant log file or journalctl for a CMD entry matching your job's command and today's timestamp. On Ubuntu, that's grep CRON /var/log/syslog; on RHEL-based systems, grep CRON /var/log/cron; on systemd systems without traditional logs, use journalctl -u cron --since "24 hours ago" | grep CMD.

Why does my cron job work when I run it manually but not on schedule?

Cron runs with a minimal environment that usually lacks the PATH and shell variables your interactive session has. Scripts that rely on relative paths, unset environment variables, or assumptions about the working directory often fail silently under cron even though they run perfectly by hand.

Do I need an MTA installed to see cron job output?

Not if you redirect output yourself, but yes if you're relying on cron's built-in MAILTO mail delivery. Without a Mail Transfer Agent configured on the server, cron's mail output has nowhere to go and disappears rather than erroring — redirecting output with >> logfile.log 2>&1 avoids this dependency entirely.

Can I check crontab jobs without server or SSH access?

Yes, if the jobs are set up to ping an external monitoring service on completion. Tools like Cronevra receive an HTTP check-in from the job itself, letting you view execution history and get failure alerts from a dashboard without ever opening an SSH session.