Cron job not running? Find the reason in the log, PATH and environment

1. Did cron start the job?

grep CRON /var/log/syslog | tail -n 20    # Debian / Ubuntu
sudo journalctl -u cron -n 20             # Debian / Ubuntu, with systemd
sudo tail -n 20 /var/log/cron             # RHEL / Rocky / AlmaLinux (cronie)

A started job leaves a line like this:

CRON[2481]: (guest) CMD (/opt/scripts/backup.sh >> /var/log/backup-cron.log 2>&1)

• The line is there → cron did its part; the job itself fails. Go to section 3.
• No line at all → cron never started it. Check that cron runs (systemctl status cron, or crond on RHEL), then the schedule and the file (section 2).

2. Cron never starts it

The schedule isn’t what you think. 0 2 * * 1 is Monday at 02:00 — in the server’s time zone, which on many servers is UTC (timedatectl shows it). Paste the line into the Cron Builder to see the next run times in plain words.

One rule surprises everybody: if you set both the day of the month and the day of the week, cron runs when either matches. 0 9 1 * 1 runs on the 1st of every month and on every Monday.

The entry is in the wrong place. Your own crontab (crontab -e) has five time fields and the command. /etc/crontab and files in /etc/cron.d/ have a user field between them:

# crontab -e
30 3 * * * /opt/scripts/backup.sh
30 3 * * * root /opt/scripts/backup.sh

Files in /etc/cron.d are ignored silently when:

• the file name has a dot in it (backup.cron) — on Debian/Ubuntu only letters, digits, - and _ count;
• the file isn’t owned by root, or others can write to it;
• the last line doesn’t end with a newline — the last job is then simply skipped. Add an empty line at the end.

3. The job starts, then fails

Make it tell you why. Append its output to a log file, errors included:

*/5 * * * * /opt/scripts/backup.sh >> /var/log/backup-cron.log 2>&1

Without that, cron tries to email the output to the user. Most servers have no mail system, so it’s thrown away — Debian/Ubuntu even logs it: (CRON) info (No MTA installed, discarding output).

Then look for these, in order:

The PATH is minimal. Cron runs jobs with PATH=/usr/bin:/bin. Anything in /usr/local/bin, /usr/sbin, /snap/bin or your home folder is “command not found”. Use full paths (/usr/local/bin/aws), or set PATH at the top of the crontab:

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

None of your shell setup is loaded. No .bashrc, no .profile, no variables you exported, no conda or nvm, no SSH agent. If the script needs a variable, set it in the script or the crontab.

The shell is sh, not bash. Cron runs the command line with /bin/sh (dash on Debian/Ubuntu). Bash syntax like [[ … ]] or source fails there. Put #!/bin/bash in the script and call the script, not the commands inline — or add SHELL=/bin/bash to the crontab.

% means “new line” in a crontab. Everything after the first % becomes the command’s input. Escape it:

0 1 * * * tar czf /backup/site-$(date +\%F).tar.gz /var/www     # \% , not %

Relative paths. The job starts in the user’s home folder, not where the script lives. Use absolute paths, or cd to the right folder first.

Permissions. The script needs the execute bit (chmod +x), and the cron user must be able to read everything it touches — see Permission denied when running a script.

4. Reproduce cron’s environment

The fastest way to see what cron sees: run the script with an empty environment, the way cron would.

env -i HOME=$HOME SHELL=/bin/sh PATH=/usr/bin:/bin /bin/sh -c '/opt/scripts/backup.sh'

If it fails here and works in your normal shell, the difference is the environment — usually PATH or a missing variable.