Cron Job Not Running? Check These 8 Things First

You wrote a script. It works perfectly when you run it by hand. You add it to cron, wait for the scheduled time, and nothing happens. No output, no error, no indication that anything went wrong. This is the most common cron complaint, and it almost always comes down to one of nine causes.

1. The cron daemon is not running

Before debugging your job, verify the scheduler itself is alive. The cron daemon is a system service that can be stopped by a reboot, a package update, or a misconfigured init system. For a full guide to managing crontab — editing, listing, and common pitfalls — start there if you’re new to the tooling.

On systemd-based systems (Ubuntu, Debian, CentOS 7+, RHEL):

systemctl status cron
# or on CentOS/RHEL:
systemctl status crond

You should see Active: active (running). If not:

sudo systemctl start cron
sudo systemctl enable cron

On older init systems:

service cron status
# If stopped:
sudo service cron start

On macOS, the equivalent is launchd, but if you’re using crontab -e on macOS, the cron daemon is typically managed automatically. Verify with:

sudo launchctl list | grep cron

If the daemon isn’t running, none of your jobs will fire, no matter how correct the cron expression is.

2. Syntax errors in the cron expression

A malformed expression silently does nothing. If you need a refresher on the five fields, operators, and special strings, see the cron syntax cheat sheet. Common mistakes:

• Six fields instead of five. Some systems (like Spring or Quartz) use a seconds field. Standard crontab uses five fields only: minute, hour, day-of-month, month, day-of-week.
• Swapped minute and hour. 0 9 * * * runs at 9:00 AM. 9 0 * * * runs at 12:09 AM. These look similar but fire 9 hours apart.
• Using names incorrectly. 0 9 * * MON works on some systems but not all. Use numeric values (0 9 * * 1) for portability.
• Day-of-week numbering. Sunday is 0 on most systems but 7 on others. Both usually work, but check your platform.
• Missing newline at end of file. Some cron implementations silently ignore the last line of a crontab if it does not end with a newline character. Always make sure there is a blank line after your last cron entry. This is easy to miss with crontab -e and is invisible when you review the file.

Validate your expression before deploying. Paste it into the cron expression explainer to see the exact next run times, or build one from scratch with the cron expression generator. See 25 cron expression examples for tested, copy-paste schedules.

3. Unescaped % characters in the command

The % character has special meaning in crontab: it is interpreted as a newline. Everything after the first unescaped % is fed to the command as stdin, not passed as part of the command line. This breaks commands silently with no error in the cron log.

The most common victim is date formatting:

# Broken — cron sees "date +" and pipes "Y-" as stdin
0 2 * * * /usr/bin/tar czf /backups/db-$(date +%Y-%m-%d).tar.gz /var/lib/mysql

# Fixed — escape every % with a backslash
0 2 * * * /usr/bin/tar czf /backups/db-$(date +\%Y-\%m-\%d).tar.gz /var/lib/mysql

Any % in your cron command must be escaped as \%. This applies everywhere in the command string, not just in date — curl payloads, awk format strings, and anything else that contains a literal percent sign.

If your command has many % characters, put the logic in a shell script and call that from cron instead. Scripts referenced by cron are not subject to crontab’s % parsing:

# The script itself can use % freely — only the crontab line parses %
0 2 * * * /home/app/scripts/backup.sh

This issue does not appear when you test commands in an interactive shell, which makes it especially hard to catch. If your cron log shows the job ran but the output or files are wrong, check for unescaped % characters first.

4. PATH and environment variable issues

This is the single most common reason a script works manually but fails in cron. When you open a terminal, your shell loads ~/.bashrc, ~/.bash_profile, or ~/.zshrc, which set up your PATH, language settings, and other environment variables. Cron does none of this. It runs with a minimal environment, typically just:

SHELL=/bin/sh
PATH=/usr/bin:/bin
HOME=/home/youruser

If your script calls python, node, php, or any command that lives outside /usr/bin:/bin, cron will not find it. The fix is to use absolute paths everywhere:

# Wrong — cron can't find python3
* * * * * python3 /home/app/scripts/sync.py

# Right — absolute path to the interpreter
* * * * * /usr/bin/python3 /home/app/scripts/sync.py

Find the absolute path of any command with which:

which python3
which node
# /usr/local/bin/node

Alternatively, set PATH at the top of your crontab:

PATH=/usr/local/bin:/usr/bin:/bin

0 * * * * python3 /home/app/scripts/sync.py

If your script depends on other environment variables (API keys, database URLs), define them in the crontab or source them explicitly:

0 * * * * . /home/app/.env && /usr/bin/python3 /home/app/scripts/sync.py

5. Permission problems

Cron runs jobs as the user who owns the crontab. If the script file is not executable or is owned by a different user, it will fail.

# Make the script executable
chmod +x /home/app/scripts/sync.sh

# Verify ownership
ls -la /home/app/scripts/sync.sh

Other permission issues to check:

• The script writes to a directory the cron user cannot access. A job running as www-data cannot write to /root/logs/.
• SELinux or AppArmor is blocking execution. Check audit.log or dmesg for denial messages.
• The crontab was edited by root but should run as a service user. Use crontab -u www-data -e to edit another user’s crontab.

If you put your cron entry in /etc/cron.d/, the file format requires a username field between the schedule and the command:

# /etc/cron.d/myapp — note the username field
0 * * * * www-data /usr/bin/php /var/www/app/artisan schedule:run

Files in /etc/cron.d/ must be owned by root and must not be group-writable or world-writable, or cron will refuse to load them.

6. The script works manually but not in cron

If your script runs fine from an interactive terminal but fails silently in cron, the difference is almost always the environment. Beyond PATH (covered above), watch for:

• Working directory. Cron does not cd into your project directory. Use absolute paths for all file references, or add an explicit cd at the start of the command:

0 * * * * cd /var/www/app && /usr/bin/php artisan schedule:run

• Shell differences. Cron uses /bin/sh by default, not bash. If your script uses bash-specific syntax (arrays, [[ ]] tests, process substitution), either set SHELL=/bin/bash in the crontab or add a shebang line:

#!/bin/bash
# Now bash-specific syntax works

• Missing display server. Scripts that use GUI tools or need a DISPLAY variable will fail in cron. This includes anything that spawns a browser or uses graphical libraries.

• Virtual environments. Python scripts that depend on a virtualenv need to activate it or use the virtualenv’s Python binary directly:

0 * * * * /home/app/venv/bin/python /home/app/scripts/sync.py

7. Output and error swallowing

By default, cron sends a job’s stdout and stderr to the local mail system via MAILTO. If no mail transfer agent is configured (common on modern servers), that output is silently discarded. Your job could be failing with a clear error message, but you never see it.

Redirect output to a log file:

0 * * * * /usr/bin/python3 /home/app/scripts/sync.py >> /var/log/myapp/sync.log 2>&1

Breaking this down:

• >> appends stdout to the log file
• 2>&1 redirects stderr to the same destination

To capture stdout and stderr separately:

0 * * * * /usr/bin/python3 /home/app/scripts/sync.py >> /var/log/myapp/sync.log 2>> /var/log/myapp/sync-error.log

If you want email notifications, set MAILTO at the top of the crontab and make sure a mail transfer agent (like postfix or msmtp) is installed:

MAILTO=[email protected]

0 * * * * /usr/bin/python3 /home/app/scripts/sync.py

To suppress output for a job you know is noisy but working:

0 * * * * /usr/bin/python3 /home/app/scripts/sync.py > /dev/null 2>&1

Be careful with that last one. Sending output to /dev/null is the reason most cron debugging is hard in the first place. Use it sparingly.

8. Timezone mismatches

Cron evaluates expressions against the system clock. If your server is set to UTC but you expected the job to run at 9 AM in your local timezone, it will fire at the wrong time.

Check the system timezone:

timedatectl
# or
cat /etc/timezone
# or
date +%Z

If the server is in UTC and you need a job to run at 9 AM US Eastern (UTC-5 / UTC-4 during DST):

# UTC equivalent of 9 AM ET (standard time)
0 14 * * * /usr/bin/python3 /home/app/scripts/report.py

The problem with this approach is daylight saving time. The UTC offset changes twice a year, so your “9 AM” job drifts by an hour.

Better approaches:

• Set the crontab timezone (supported on some systems):

CRON_TZ=America/New_York
0 9 * * * /usr/bin/python3 /home/app/scripts/report.py

• Use UTC consistently and handle display-time conversion in your application code. This is the safest approach and the one every managed scheduler uses.

9. Overlapping jobs

If a job takes longer than the interval between runs, you get concurrent executions. A backup script that takes 90 minutes, scheduled every hour, will have two instances running simultaneously by the second hour. This can cause data corruption, duplicate processing, or resource exhaustion.

Use flock to enforce mutual exclusion:

# Only one instance runs at a time — subsequent attempts are skipped
0 * * * * /usr/bin/flock -n /tmp/sync.lock /usr/bin/python3 /home/app/scripts/sync.py

The -n flag makes flock exit immediately (non-blocking) if the lock is already held. Without -n, it waits — which is rarely what you want for cron jobs.

For more complex concurrency control, use a timeout:

# Wait up to 60 seconds for the lock, then give up
0 * * * * /usr/bin/flock -w 60 /tmp/sync.lock /usr/bin/python3 /home/app/scripts/sync.py

If your jobs are regularly overlapping, the real fix is to either increase the interval or optimize the job’s execution time.

Checking the cron logs

When none of the nine causes above explain the problem, check whether cron even attempted to run your command. Cron logs every attempt, and these logs are the fastest way to narrow down the issue.

Debian/Ubuntu:

grep CRON /var/log/syslog

CentOS/RHEL:

cat /var/log/cron

systemd-based systems (any distro):

journalctl -u cron --since "1 hour ago"
# or for crond:
journalctl -u crond --since "1 hour ago"

A normal cron log entry looks like:

Mar 19 09:00:01 server CRON[12345]: (www-data) CMD (/usr/bin/php /var/www/app/artisan schedule:run)

If you see the entry, cron ran the command. The problem is in your script. If there is no entry at the expected time, the issue is with the cron expression, the daemon, or the crontab itself.

To verify your crontab is loaded correctly:

crontab -l

If the output is empty or missing your entry, the crontab was not saved properly. Re-edit with crontab -e.

Tired of debugging cron infrastructure? If you’re spending more time on PATH issues, silent failures, and log wrangling than on the actual jobs, a managed job scheduling service eliminates the entire category. Recuro runs your scheduled HTTP requests with built-in execution logs, automatic retries, configurable failure alerts, and a dashboard that shows every job’s status and history. You define the cron expression and the endpoint URL — everything else is handled.

If you’re already running cron jobs and want to add monitoring without migrating, see how to monitor cron jobs and get alerts.