Console9

Crontab: job not running

Diagnose and fix cron jobs that fail to execute, including PATH issues, permission errors, and missing output.

The crontab scheduler silently skips a job when the cron daemon cannot locate the script, lacks permission to execute it, or encounters an environment variable mismatch.

When crontab Jobs Fail to Run

A crontab job appears to not run when the expected output — a log entry, a file change, or an email — never appears at the scheduled time. The cron daemon does not display errors in the terminal because cron jobs execute in the background without a controlling terminal session.

A crontab job also fails to run when the cron daemon itself is not active. Systems that have been recently provisioned, rebooted, or migrated from a container image may not have the cron service enabled by default.

What Causes "Job Not Running" in crontab

Missing PATH Environment Variable in crontab

The cron daemon executes jobs with a minimal PATH environment variable — typically /usr/bin:/bin only. Commands that rely on executables in /usr/local/bin, /snap/bin, or custom directories fail with "command not found" errors. The cron daemon does not load the user's .bashrc, .bash_profile, or .profile files, so any PATH modifications defined in those files do not apply to cron jobs.

This is the single most common cause of crontab jobs not running. A script that works when executed manually in a terminal fails under cron because the terminal session has a richer PATH than the cron environment provides.

File Permission Errors in crontab Jobs

The cron daemon refuses to execute a script that lacks the executable permission bit. A script file with permissions 644 (read/write for owner, read for others) causes cron to skip the job without producing an error message. The script must have 755 or 700 permissions for cron to execute it.

Missing Shebang Line in the Scheduled Script

The cron daemon does not assume Bash as the interpreter. A script without a shebang line ( #!/bin/bash) as its first line causes cron to interpret the script with /bin/sh. Shell-specific syntax like arrays, [[ ]] tests, and source commands fail silently under /bin/sh.

Incorrect crontab Expression Syntax

The crontab time expression uses five fields: minute, hour, day of month, month, and day of week. A common mistake is reversing the minute and hour fields, which causes the job to run at an unexpected time rather than not at all. Another syntax error is omitting the newline at the end of the crontab file — the cron daemon ignores the last line if it does not end with a newline character.

cron Daemon Not Running

The cron service must be active for any crontab job to execute. On systemd-based Linux distributions, the cron daemon runs as the cron or crond service. Container images and minimal server installations often do not include or enable the cron service by default.

How to Fix "Job Not Running" in crontab

Fix 1: Set PATH Explicitly in the crontab File

  1. Open the crontab editor to add a PATH definition at the top of the crontab file:
crontab -e
  1. Add the PATH variable before any job entries. The crontab PATH line defines which directories the cron daemon searches for executables:
PATH=/usr/local/bin:/usr/bin:/bin

0 2 * * * /home/user/scripts/backup.sh >> /home/user/logs/backup.log 2>&1

Fix 2: Use Absolute Paths for All Commands

  1. Replace every command inside the script with its absolute path. Locate the absolute path of a command using which:
which mysqldump
/usr/bin/mysqldump
  1. Replace mysqldump with /usr/bin/mysqldump in the script. Apply this to every command the script calls — including echo, date, gzip, and curl.

Fix 3: Fix Script Permissions

  1. Set the executable permission on the script file using the chmod command:
chmod +x /home/user/scripts/backup.sh

Fix 4: Add the Shebang Line

  1. Verify the first line of the script contains the correct shebang. Open the script and confirm it starts with #!/bin/bash:
head -1 /home/user/scripts/backup.sh

If the first line is not #!/bin/bash, add it as the very first line of the file.

Fix 5: Start the cron Daemon

  1. Check whether the cron service is running on the system:
systemctl status cron
  1. Start and enable the cron service if it is inactive:
sudo systemctl enable cron
sudo systemctl start cron

How to Verify the Fix

The crontab job produces output in its log file after the next scheduled execution. To test immediately without waiting for the schedule, run the script manually using the same environment that cron provides:

env -i /bin/bash -c '/home/user/scripts/backup.sh'

The env -i command strips all environment variables, simulating the minimal cron environment. If the script fails under env -i but succeeds in a normal terminal session, the problem is confirmed to be a PATH or environment issue.

Verify the cron log for execution entries. The cron daemon logs job execution to syslog on most Linux distributions:

grep CRON /var/log/syslog | tail -10

Each cron execution produces a log entry showing the user, the command, and the timestamp.

Edge Cases and Variations

The crontab command on macOS uses launchd as the underlying scheduler, not the traditional cron daemon. macOS cron jobs may behave differently when the system is asleep — launchd defers jobs until the system wakes, while Linux cron skips missed executions entirely. Use anacron on Linux to handle jobs that should run after a missed schedule.

The crontab file for the root user is separate from regular user crontab files. A job that requires root privileges must be added with sudo crontab -e, not crontab -e. Running crontab -e as a regular user and prefixing the command with sudo inside the crontab entry does not work — cron does not have access to the user's sudo credentials.

© 2026 - Console9