Fix a Cron Job Not Running on Linux
cron job not runningscheduled task not firingworks manually but not in cronA cron job that runs fine by hand but never fires on schedule is a classic. It's almost always the environment cron runs in — PATH, paths, or permissions. Here is how to debug it.
If a job runs perfectly by hand but never fires on schedule, it's almost always that cron runs in a stripped-down environment. These are the usual culprits, most common first:
| Symptom | Cause | Fix |
|---|---|---|
| "command not found" in cron only | Cron has a minimal PATH | Use absolute paths (/usr/bin/php …) |
| Script runs but can't find its files | Cron doesn't run from the script folder | cd into it, or use absolute paths inside |
| Nothing happens at all | Bad crontab syntax or missing final newline | Fix the 5 time fields; end the file with a newline |
| Permission denied | Script not executable / wrong user | chmod +x, and check whose crontab it's in |
| Works sometimes, not always | Wrong timezone or overlapping runs | Check the system TZ; add a lock to avoid overlap |
Is cron even running?
Confirm the cron service is active and check the schedule:
systemctl status cron # or crond on RHEL/Alma
crontab -l # list this user's jobsCause 1: a minimal PATH
Cron runs with a bare environment, so commands that work in your shell (because of your PATH) fail. Use absolute paths for everything:
# bad: php script.php
# good:
0 * * * * /usr/bin/php /home/user/script.phpCause 2: relative paths inside the script
Cron doesn't run from your script's folder. Either cd into it first or use absolute paths inside the script:
0 3 * * * cd /home/user/app && /usr/bin/php backup.phpCause 3: see the actual error — log the output
By default you never see why it failed. Redirect output to a log and read it:
0 3 * * * /usr/bin/php /home/user/backup.php >> /home/user/cron.log 2>&1A classic gotcha: a crontab file must end with a newline, or the last job silently won't run. Also remember % must be escaped as \% in cron commands.
Works by hand, not in cron = environment. Use absolute paths, log the output with >> log 2>&1, and read why it failed.
Cause 4: wrong crontab syntax or schedule
A malformed schedule (six fields instead of five, or an invalid range) makes cron silently ignore that line. Validate the schedule syntax against the man page or an online cron expression checker before assuming something else is wrong.
Cause 5: file or script permissions
If the script isn't executable, or the user cron runs as can't read/write files it touches, the job fails silently unless you're logging output. Confirm permissions with ls -l and that the crontab's user actually owns or can access the files — see permission denied on Linux.
Cause 6: wrong crontab (user vs system vs root)
A job added with crontab -e as one user won't run for another. Make sure you're editing the crontab for the user you expect, or use /etc/cron.d/ for system-wide jobs, which need an extra username field.
How to prevent cron issues
- Always use absolute paths for commands and files.
- Always redirect output to a log.
- Test the exact command manually as the cron user, not your own login.
- Keep a monitoring/alert — even a simple heartbeat ping — on critical jobs like backups.
Related errors
If the job runs but a command inside it fails with a permissions error, see permission denied on Linux. For checking what resources a scheduled job is using, see checking CPU/RAM/disk usage. New to the shell? Start with essential Linux commands.
A VDS for your scheduled tasks
Run cron jobs, backups and bots reliably on our protected NVMe VDS plans in Frankfurt.
Frequently asked questions
Why does my cron job work manually but not on schedule?
Cron runs with a minimal environment and a bare PATH, and not from your script's directory. Commands or relative paths that rely on your shell setup fail. Use absolute paths and cd into the working directory.
How do I see why a cron job failed?
Redirect its output to a log file by appending >> /path/cron.log 2>&1 to the cron line. Then read that log — it shows the actual error cron hit.
Why isn't my last cron job running?
A crontab file must end with a newline character, or the final line is ignored. Add a blank line at the end. Also escape any % signs as \% in the command.
How do I test a cron job as the exact user it will run as?
Use su - username -c "your command" (or sudo -u username command) to run it exactly as cron would, including its minimal environment. If it fails there but works in your own shell, that confirms an environment/permissions issue.
Why does my cron job fail only on some servers?
Different distros ship different default PATHs and shells for cron. Always set explicit absolute paths and, if needed, a SHELL=/bin/bash line at the top of the crontab so behavior is consistent everywhere.
Can I schedule a cron job to run every few minutes?
Yes — use */5 * * * * for every 5 minutes, for example. Just be careful that fast schedules don't overlap if the job can run longer than the interval; add a lock file check if that's a risk.
Related articles
Fix SSH "Connection refused" / "Connection timed out"
SSH "connection refused" vs "timed out" — what each means and the exact steps to fix them.
Read fix Linux & VPSFix "Permission denied" on Linux (chmod & chown Explained)
"Permission denied" on a script or file? Understand chmod/chown and fix it the right way.
Read fix Linux & VPSHow to Check CPU, RAM & Disk Usage on a Linux Server
The essential commands to check CPU, RAM and disk on Linux — and find what's eating them.
Read fix
