Cron Job 'Installed' but Never Runs

Cron failures are boringly consistent: PATH differences, silent script errors, or the crontab you think is installed isn't.

What you'll see

Root causes

Minimal PATH in cron

cron runs with /usr/bin:/bin. Anything installed elsewhere (rake, docker, npx) is 'command not found' — mailed to a mailbox nobody reads.

Script depends on your environment

Env vars, virtualenv activation, or relative paths that assume a login shell.

Wrong crontab scope

Installed in the user crontab but needs root, or edited the file without crontab -l ever picking it up.

Fix it

  1. Confirm the schedule is actually registered
    crontab -l; sudo crontab -l
  2. Point cron at full paths and log everything
    17 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
  3. Check what cron says happened
    grep CRON /var/log/syslog | tail
  4. Debug with cron's own environment
    */5 * * * * /bin/printenv > /tmp/cron-env.txt

Field note

For anything with dependencies, a systemd timer with an explicit Environment and WorkingDirectory beats cron — you also get journalctl logs for free.

Common questions

The crontab entry works when I run the command manually. Why not from cron?

Cron runs with a minimal environment: PATH, HOME, and shell differ from your interactive session. Absolute paths for binaries and files, plus a PATH line in the crontab, fix the classic variant.

How do I debug a silent cron failure?

Redirect output to a file (>> /tmp/job.log 2>&1) and check the system log (grep CRON /var/log/syslog). Silent cron jobs are almost never silent — the output just goes nowhere.

Related fixes

Ship it right the first time

Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.

Browse the template store →

One-time. Yours to modify. Instant download from the NinjaOps template store.