Fix Cron Job Execution Failed on Ubuntu 22.04

You set up a cron job. You checked the syntax. You even restarted the cron service. But the job still doesn't run. Or maybe it runs but does nothing useful—no output, no errors, just silence.

This usually happens when you write a command that works perfectly in your terminal but fails inside cron. The trigger is almost always the same: you're testing a backup script or a log rotation that calls a program like rsync, mysqldump, or duplicity. In your shell, it works. In cron, it doesn't. I've seen this a hundred times.

The Real Root Cause

Cron runs with a very limited environment. It doesn't load your .bashrc or .bash_profile. That means PATH is set to something like /usr/bin:/bin—nothing more. If your script uses a program installed in /usr/local/bin or /opt, cron can't find it. No error message, no warning. The job just fails silently.

Another common cause: permissions. Your script might be owned by root, but you're running it from a user crontab. Or the script isn't executable. Or the output file location isn't writable by the cron user.

Step-by-Step Fix

These steps work on Ubuntu 22.04 and most modern Linux distros. I'll assume you have a script called /home/you/backup.sh that checks mail or writes logs.

Step 1 — Check if cron is actually running

Before anything else, confirm the cron daemon is alive. Open a terminal and type:

systemctl status cron

You should see active (running). If it's dead, start it:

sudo systemctl enable --now cron

After this, run systemctl status cron again. You should see green text saying active (running).

Step 2 — Add full PATH and explicit shebang in your script

The most reliable fix: put a proper shebang at the top of the script and set the PATH inside it. Open your script with any text editor, for example:

nano /home/you/backup.sh

Make the first line look like this:

#!/bin/bash

Then, right under the shebang, add:

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

That's the full system PATH. Save the file (Ctrl+O, then Enter, then Ctrl+X in nano).

Step 3 — Make the script executable

Without the executable permission, cron won't even try to run the script. Run:

chmod +x /home/you/backup.sh

Verify with ls -l /home/you/backup.sh. You should see -rwxr-xr-x at the start.

Step 4 — Edit your crontab with full paths and redirect output

Open your user crontab:

crontab -e

Your existing line probably looks like:

0 2 * * * /home/you/backup.sh

Change it to use the full path to bash and capture both stdout and stderr:

0 2 * * * /bin/bash /home/you/backup.sh >> /home/you/backup.log 2>&1

This sends all output to a log file. After saving, you can check that file later.

Step 5 — Test the cron job manually

Wait for the scheduled time? No. Run the command that cron would run, directly:

/bin/bash /home/you/backup.sh >> /home/you/backup.log 2>&1

If this works, the problem is definitely cron's environment. If it fails, fix the script first.

Step 6 — Check the cron log

Cron logs to syslog. On Ubuntu it's usually in /var/log/syslog. Search for your cron job or script name:

grep -i cron /var/log/syslog | grep backup

You'll see lines like:

Feb 15 02:00:01 server CRON[12345]: (you) CMD (/bin/bash /home/you/backup.sh >> /home/you/backup.log 2>&1)

If you see that line but the script didn't work, check the log file. If you don't see any line, cron didn't run the job—check your crontab syntax again.

What to Check If It Still Fails

Permissions on the log file: The user running cron must be able to write to /home/you/backup.log. Run touch /home/you/backup.log and then ls -l /home/you/backup.log. The owner should be your username.
Environment variables: If your script uses custom variables like DB_PASSWORD or HOME, define them inside the script or crontab. Cron doesn't pass them.
Email output: By default, cron sends output to the user's local mail. Check with mail command (install mailutils if needed). If you see error messages there, they'll point to the exact problem.
Systemd timers: If you're on a headless server, consider switching from cron to systemd timers. They're more predictable and have better logging. But that's a different topic.

One more thing: I've seen people put the script in /etc/cron.hourly and wonder why it runs as root instead of their user. If you need user-level execution, stick with crontab -e. Root crontab is for system tasks only.