$ Linux One Liners
Back to problems

problem hub

Read-only first

Cron job not running on Linux

Check the active crontab, cron service, logs, user, environment, and script assumptions before rewriting the schedule.

Safest first command

crontab -l

Before you run this

Expected output: The current user crontab, including environment assignments and active schedule lines, or a message that no crontab exists.

When not to use it: Do not edit schedules on production jobs until you know which user owns the job and where its output or logs go.

Expected output example

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
*/5 * * * * /srv/app/bin/backup >>/var/log/app-backup.log 2>&1

How to read the result

Confirm the job exists for the expected user, has an explicit command path, and records output somewhere. Cron has a smaller environment than an interactive shell.

What to check next

No crontab for the expected user

Means: You may be checking the wrong account or the job is in system cron instead.

Next step: Inspect system cron locations before adding a duplicate job.

Find System Cron Files Fast

Job has relative paths or no PATH

Means: The script may work manually but fail under cron environment.

Next step: Map schedules to commands and add logging before changing logic.

Turn Cron Into a Readable Table

No log or mail trail

Means: The job may be failing silently.

Next step: Use a heuristic to find jobs without obvious output capture; this does not prove the job is broken.

Show the Real User Cron Jobs

Cron decision tree

Prove the job exists for the expected user, then check whether cron is running, whether logs show executions, and whether the command depends on an interactive environment. Only then edit the schedule or script.

  1. crontab -l
  2. grep CRON /var/log/syslog | tail -50
  3. journalctl -u cron --since '1 hour ago' --no-pager
  4. systemctl status cron --no-pager

Environment and working directory branch

Cron jobs often fail because PATH, HOME, shell, and working directory differ from a terminal session. Use absolute paths and capture output before changing the schedule. The grep pipeline below is only a heuristic for jobs without obvious output capture; it does not prove the job is broken.

  1. crontab -l
  2. crontab -l | grep -v '^[[:space:]]*#' | grep -vE '>>|2>&1|MAILTO=|logger'

Bad fixes to avoid

Do not add duplicate cron lines under another user. Do not chmod scripts recursively. Do not redirect output to /dev/null while debugging. Do not assume a command that works in your shell has the same environment under cron.

Common causes

  • Wrong user crontab
  • Cron service stopped
  • PATH or working-directory assumption
  • Script not executable
  • No output capture or mail path
  • run-parts filename skipped

What not to change yet

  • Do not create a duplicate schedule before finding the owner.
  • Do not silence output during diagnosis.
  • Do not edit system cron files without a rollback copy.

Stop and escalate if

  • The next step could interrupt users, remove data, or lock out access.
  • The output includes secrets, customer data, or private infrastructure details.
  • You cannot explain the blast radius of the repair command.

platform notes

Distro and service notes

Debian/Ubuntu

Cron activity often appears in /var/log/syslog.

systemd

Some scheduled work may be systemd timers rather than cron.

supporting commands

Command path

Guides and drills