Cron Jobs Not Running? Fix It Here

Quick Fix (30 seconds)

Most cron failures are dumb stuff. Let's check the obvious first.

1. Is cron running? Run systemctl status cron or service cron status. If it's dead, start it: systemctl start cron.
2. Check your crontab with crontab -l. Make sure the job's there and formatted right. A typo in the time fields kills it silently.
3. Test the command manually. Copy the command from your crontab, run it in the terminal. If it fails, it's not cron — it's your script.

Still broken? Move to the moderate fix.

Moderate Fix (5 minutes)

Now we look at the stuff cron doesn't tell you. Cron runs with a minimal environment — no PATH, no HOME, nothing. That's the culprit 90% of the time.

1. Add full paths. In your crontab, set PATH=/usr/bin:/bin:/usr/local/bin. Or use absolute paths in your commands. Instead of python script.py, do /usr/bin/python3 /home/user/script.py.
2. Set a SHELL. Add SHELL=/bin/bash at the top of your crontab. Some systems default to /bin/sh, which can break bash scripts.
3. Check file permissions. The script must be executable (chmod +x /path/to/script). Also the user running cron needs read access to the script and write access to any log files.
4. Look at the cron log. On most distros, it's in /var/log/cron or /var/log/syslog. Grep for your job name or CRON: grep CRON /var/log/syslog | grep -i your-job. You'll see errors like "No such file or directory" or "Permission denied".

If you still see nothing, move to advanced.

Advanced Fix (15+ minutes)

Alright, this is where we dig into the weeds. Something's blocking the job from running at all.

1. Check SELinux or AppArmor. If enabled, they might block cron from executing your script. Check ausearch -m avc -ts today (SELinux) or aa-status (AppArmor). Temporarily disable to test: setenforce 0. If it works, fix the policy — don't leave it disabled.
2. Check resource limits. Look at /etc/security/limits.conf and /etc/security/limits.d/. Cron inherits these. If your job uses too many file handles or memory, it gets killed silently.
3. Review the cron service unit file (systemd systems). Run systemctl cat cron.service. See if there's a ReadOnlyPaths or ProtectHome directive that blocks access to your script. Edit with systemctl edit cron.service and override those.
4. Check for duplicate cron entries. Multiple crontabs for the same user can override each other. Run crontab -l for each user that might have schedules. Also check /etc/crontab and /etc/cron.d/ for system-wide jobs.
5. Test with a dummy job. Create a simple one: * * * * * touch /tmp/cron_test_$(date +\%s). Wait a minute, check /tmp/. If it appears, your script is the problem. If not, cron itself is broken.

One last thing: If you're using anacron (common on laptops), it only runs jobs when the system's on. Check /etc/anacrontab and systemctl status anacron. Anacron and cron can conflict.

Pro tip: Always redirect output to a log file in your crontab. Add > /tmp/cron_output.log 2>&1 at the end of each job. You'll see every error.

That covers 99% of cron failures. If none of this works, your system is haunted, and you should reinstall cron from scratch: apt purge cron && apt install cron on Debian, or yum remove cronie && yum install cronie on RHEL.