Quick, practical steps to find and fix cron jobs that silently fail on Linux. 02.02.2026 | reading time: 3 min Cron can be brutally silent when a job fails; this guide shows how to find the cause and fix it with commands and examples you can run now. A job that never runs Reproduce the failure first: list the crontab with `crontab -l` and inspect the entry; for example a user crontab might contain ```bash 0 2 * * * /home/deploy/backup.sh >> /var/log/backup.log 2>&1 ``` then run the script as the cron user to test: `sudo -u deploy /home/deploy/backup.sh` and check its immediate output and exit code; if that runs but cron does not, check the scheduler logs with `journalctl -u cron --since "1 hour ago"` or examine `/var/log/syslog` for lines from CRON, for example ```bash Feb 01 02:00 host CRON[12345]: (deploy) CMD (/home/deploy/backup.sh >> /var/log/backup.log 2>&1) Feb 01 02:00 host CRON[12345]: (deploy) ERROR: bad shebang ``` which tells you the interpreter or permissions are wrong. Common root causes to check Look for environment and permission problems first: cron runs with a minimal PATH and different SHELL, so absolute paths matter; verify the script has the execute bit and a correct shebang with `ls -l /home/deploy/backup.sh` and `head -n1 /home/deploy/backup.sh`; check ownership and SELinux contexts; confirm the crontab line uses the correct user (system crontabs include a user field); inspect `MAILTO` and redirected logs because cron may send errors by mail rather than to your file; also consider that `run-parts` and anacron behave differently and that systemd timers can replace cron for better logging and dependency handling. Step-by-step practical debugging Do this checklist: 1) `crontab -l` to ensure the job is installed; 2) `sudo -u <user> env > /tmp/env.txt` and compare with your interactive environment to find missing vars; 3) run the command under the exact environment cron uses: `env -i SHELL=/bin/bash PATH=/usr/bin:/bin sudo -u deploy /home/deploy/backup.sh` ; 4) add temporary logging and `set -x` in the script or run `bash -x /home/deploy/backup.sh` to trace execution; 5) inspect `journalctl -u cron` and `/var/log/syslog` for timestamps and exit messages; 6) if SELinux blocks execution, check `ausearch -m avc` or `audit.log` and adjust policies carefully. When cron isn't the right tool If jobs require complex environment, ordering or robust failure handling prefer `systemd` timers or a simple wrapper that creates predictable environment and logs; cron is best for simple, periodic tasks but systemd gives richer state, retries and unified logs through `journalctl`. Wrap-up and next steps Start by reproducing the job outside cron, then inspect scheduler logs, correct environment and permission issues, and add lightweight logging for future problems; deepen your Linux troubleshooting skills and consider formal certification such as CompTIA Linux+ or LPIC-1, with intensive exam preparation available at bitsandbytes.academy. Join Bits & Bytes Academy First class LINUX exam preparation. troubleshooting scripting processes infrastructure
