Cron Job Not Running? 7 Common Causes and How to Fix Them

Why is my cron job not running? A cron job usually fails to run for one of seven reasons: (1) the crontab syntax is wrong, (2) cron isn't installed or the daemon is stopped, (3) the script path is relative instead of absolute, (4) PATH and environment variables differ under cron, (5) file permissions or the execute bit are missing, (6) the user's crontab differs from root's, or (7) the job ran but failed silently. The fastest way to know which is to log output (>> /tmp/cron.log 2>&1) — and the only way to know it stopped at all is external heartbeat monitoring.

Most "cron job not running" problems fall into a handful of buckets. Work them in order, top to bottom.

First, Confirm Cron Itself Is Running

Before debugging your job, confirm the daemon is alive:

systemctl status cron    # Debian/Ubuntu
systemctl status crond   # RHEL/CentOS/Fedora

If it's inactive, start it with sudo systemctl start cron. No daemon, no jobs — period.

The 7 Most Common Causes

1. Crontab Syntax

The five time fields (min hour day month weekday) are the usual culprit. * * * * * runs every minute; 30 2 * * * runs at 02:30 daily. Validate the expression before you trust it, and confirm what's actually installed with crontab -l. Note that @reboot and other shortcuts aren't supported on every platform.

2. Relative Paths

Cron runs with a minimal working directory. python script.py will fail where python /home/app/script.py works. Use absolute paths for everything — the interpreter, the script, and any files it reads or writes.

3. Environment and PATH

This is the single most common silent failure. Your interactive shell loads .bashrc; cron does not. Under cron, PATH is often just /usr/bin:/bin. Commands that work in your terminal (node, python3, aws) may not be found. Fix it by using absolute binary paths (/usr/local/bin/node) or by setting PATH= at the top of the crontab.

4. Permissions and the Execute Bit

The script must be executable (chmod +x script.sh) and the cron user must be able to read it and everything it touches. A job that writes to /var/log/myapp/ will fail if that directory is root-owned and the job runs as a service user.

5. The Wrong User's Crontab

crontab -e edits your crontab. A job in root's crontab won't appear in a deploy user's crontab -l. System jobs also live in /etc/crontab and /etc/cron.d/. Check all of them.

6. It Ran — and Failed

Cron happily runs a job that exits non-zero and tells no one. Always capture output by appending a redirect to the crontab line, so both stdout and stderr land somewhere you can read:

0 2 * * * /opt/backup.sh >> /var/log/mycron.log 2>&1

7. It Stopped Running Entirely

This is the one none of the above catches. If the server reboots and the daemon doesn't come back, if a deploy wipes the crontab, or if the box is under load and skips the tick, your job simply doesn't run — and there is no error to grep, because nothing executed. Logs only exist for jobs that ran. A missing execution is an absence, not an error.

A 60-Second Diagnostic Checklist

1. systemctl status cron — is the daemon up?
2. crontab -l (and sudo crontab -l, /etc/cron.d/) — is the entry there?
3. Absolute paths for interpreter, script, and files?
4. PATH= set, or absolute binaries used?
5. chmod +x and the correct owner?
6. Output redirected to a log file?
7. Something watching that the job runs at all?

The Blind Spot: A Job That Stops Triggers No Error

Items 1 through 6 you can grep for after the fact. Item 7 you can't — a missed run leaves no trace. That's what external heartbeat monitoring is for: your job sends a ping when it finishes, and if the ping doesn't arrive on schedule, you get alerted. cronradar.com">CronRadar does this with a single curl or a one-line SDK call — and if you use a framework scheduler (Laravel, Hangfire, Celery, Quartz, node-cron), it auto-discovers your jobs so you don't register them by hand.

Frequently Asked Questions

How do I check if a cron job ran?

Redirect the job's output to a log file and check the timestamps. To catch runs that were missed entirely — where no log is written — use external heartbeat monitoring.

Why does my cron job work manually but not in crontab?

Almost always PATH and environment differences. Cron doesn't load your shell profile, so binaries and variables available in your terminal may be missing under cron.

Does cron log anywhere by default?

Cron's invocation is usually logged to /var/log/syslog (grep for CRON) or journalctl -u crond, but your script's own output is not captured unless you redirect it.