Linux Cron Job Not Running Fix

What Does This Error Mean?

Cron is Linux's built-in task scheduler — it runs commands automatically on a schedule. When a cron job does not run, it is usually because the cron syntax is wrong, the command path is incorrect, the script does not have execute permission, or the cron service itself is stopped. Cron errors are almost always silent, making them tricky to diagnose without checking logs.

Affected Models

Ubuntu
Debian
Fedora
CentOS
Arch Linux
Linux Mint
openSUSE

Common Causes

The crontab syntax is wrong — a missing field, an incorrect minute/hour value, or bad formatting
The command uses a full path that works in your terminal but cron has a minimal PATH with different directories
The script being run does not have execute permission set
The cron service (crond or cron) is not running
The script requires environment variables (like HOME or USER) that are not set in cron's environment

How to Fix It

Check cron syntax carefully. Edit your crontab: crontab -e. Each line has 5 time fields followed by the command: minute(0-59) hour(0-23) day(1-31) month(1-12) weekday(0-7) /path/to/command

Even a single space missing or a wrong number in the time fields causes the job to never run. Use crontab.guru (a free website) to visually check your cron expression.
Use full paths in cron commands. Cron runs with a minimal environment. Replace commands like 'python' with '/usr/bin/python' and paths like '~/scripts/backup.sh' with '/home/username/scripts/backup.sh'.

In cron, the PATH variable is usually just /usr/bin:/bin. Any command not in these directories must have its full path specified.
Set execute permission on the script. Run: chmod +x /path/to/your/script.sh to make the script executable.

A script without the execute permission runs fine when you prefix it with 'bash script.sh' but fails if called directly. cron calls scripts directly.
Check if cron is running. Run: sudo systemctl status cron (Ubuntu/Debian) or sudo systemctl status crond (Fedora/CentOS). If it is stopped, start it: sudo systemctl start cron

The cron service is usually always running, but it can be stopped accidentally or disabled.
Enable cron logging and check the output. Redirect job output to a log file by adding to the end of your cron line: >> /tmp/cronlog.txt 2>&1. Then check the log after the scheduled time: cat /tmp/cronlog.txt

By default, cron swallows all output. Adding >> /tmp/cronlog.txt 2>&1 captures both standard output and errors to a file you can inspect.

When to Call a Professional

Cron problems are always diagnosable and fixable at home. Enabling cron logging and checking the output is all it takes to identify why a job is failing. For complex automation needs, systemd timers offer a more robust and debuggable alternative to cron.

Frequently Asked Questions

Should I use cron or systemd timers for scheduled tasks?

Both work well. Cron is simpler and universally available on all Linux systems. systemd timers offer better logging, dependency management, and can be triggered by events in addition to time. For simple scheduled commands, cron is fine. For complex tasks on modern systems, systemd timers are more powerful.

How do I run a cron job as a specific user?

Edit the system-wide crontab with: sudo crontab -e -u [username]. Or edit /etc/crontab directly and add the username as the 6th field: minute hour day month weekday username /path/to/command Each user also has their own crontab accessed with: crontab -e when logged in as that user.

My cron job runs manually but not from cron. What is different?

The most common differences between your terminal and cron's environment are: PATH (cron has a minimal one), environment variables (cron sets very few), and the current working directory (cron starts in /). Add these lines at the top of your crontab to set a fuller environment: PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin and SHELL=/bin/bash