A Cron Job Works Manually but Never Runs on Schedule

The error: Running a script by hand works perfectly. The identical command in a crontab entry silently never produces results, with no obvious error anywhere.

Environment: Any Linux system using cron.

Why this happens: Cron jobs run with a minimal environment — a stripped-down PATH, no login shell profile sourced, none of the environment variables your interactive shell has quietly set up over time. A script that works fine when you run it manually can fail silently under cron simply because it relies on a binary or environment variable that isn't available in cron's much smaller default environment.

The fix:

1. Check cron's own logging first — grep CRON /var/log/syslog (Debian/Ubuntu) or journalctl -u cron/crond (RHEL-family) confirms whether the job even fired.
2. Redirect the script's own output explicitly in the crontab entry (>> /tmp/myscript.log 2>&1) rather than assuming you'd otherwise see errors — cron mails output by default only if mail is configured, which most systems don't have set up.
3. Use absolute paths for every binary and file reference inside the script — don't rely on PATH containing what your interactive shell's does.
4. If the script needs environment variables, source them explicitly at the top of the script rather than assuming cron inherited your shell's profile — it didn't.

One thing worth knowing: this is close to the single most common cron complaint there is, and the fix is almost always "use absolute paths and stop assuming cron's environment matches your terminal's" — not a bug in cron itself.