A cron job silently not running is a frustratingly common issue — this guide covers systematically diagnosing why, since the cause is rarely obvious from the symptom alone.
Step 1 — Verify the Cron Service Is Actually Running
sudo systemctl status cronIf cron itself isn't running, nothing scheduled through it will execute — the most basic check, easy to overlook.
Step 2 — Verify Your Crontab Entry Exists
crontab -lConfirm the job is actually listed — check you're viewing the crontab for the correct user (your job might have been added under a different user account than you're currently checking).
Step 3 — Check the Cron Syntax Carefully
0 2 * * * /path/to/script.shVerify the schedule syntax is actually correct for your intended timing — a subtle error in the five time fields is a common cause of a job running at an unexpected time (or seemingly never, if you're checking at the wrong expected time).
Step 4 — Check System Logs for Cron Execution Attempts
grep CRON /var/log/syslogjournalctl -u cronConfirms whether cron actually attempted to run the job at the scheduled time — if there's no log entry at all for the expected time, the scheduling itself is the issue; if there IS an entry but the job still didn't work, the issue is likely within the script/command itself.
Step 5 — Verify Full, Absolute Paths Are Used
0 2 * * * /usr/local/bin/backup.shCron's environment differs significantly from your interactive shell — PATH is much more limited; always use full absolute paths for both the script itself and any commands within it that might otherwise rely on PATH resolution.
Step 6 — Check Script Permissions
ls -la /path/to/script.shchmod +x /path/to/script.shThe script must actually be executable by the user cron runs it as.
Step 7 — Test the Script Manually as the Same User
sudo -u cronuser /path/to/script.shRunning manually as the specific user cron would use often surfaces environment-related issues (missing environment variables, different PATH) not apparent when testing as yourself/root.
Step 8 — Capture Script Output for Debugging
0 2 * * * /path/to/script.sh >> /var/log/script-output.log 2>&1Without explicit output redirection, cron's default behavior for output varies and may not be immediately visible — explicitly redirecting to a log file makes debugging much more direct.
Step 9 — Check for Environment Variable Dependencies
If your script relies on environment variables normally set in your shell profile (.bashrc, .profile), remember cron doesn't source these — explicitly set any needed environment variables within the script itself or the crontab.
Step 10 — Consider systemd Timers as a More Debuggable Alternative
See How to Set Up systemd Timers as a Cron Alternative — systemd timers integrate with journalctl logging automatically, often making this exact category of debugging significantly easier going forward.
Common Errors
"command not found" in cron logs despite the command working manually — almost always a PATH issue; use the full absolute path to the command rather than relying on it being found via PATH.
Continue Reading
- How to Schedule Tasks with Cron on a Linux VPS
- How to Set Up systemd Timers as a Cron Alternative
- How to Secure Cron Jobs and Scheduled Tasks
Browse more articles in Troubleshooting & FAQ.
