Cron Job Not Running? 9 Causes and a Fix Path

"The cron job is not running" is a chain of assumptions, and the break can be in the expression, the timezone, the daemon, the environment, or the command itself. Debugging that chain top-to-bottom finds the break in minutes; poking at the script first usually wastes hours. The nine causes below are ordered by where they sit in the chain — work through them in order and the first failing step is your answer.

Step 0 — Prove the schedule is actually due

Before touching logs, verify the expression means what you think it means in the scheduler you are using. Paste it into the Cron Expression Parser, pick the right dialect, and read the next ten run times. Three mistakes here are near-universal:

• Field-order typos. 0 9 * * * is 09:00 daily; * 9 * * * is "every minute during the 9 o'clock hour" — 60 runs, not one. If the parser's next-run list disagrees with your intention, the schedule was the bug.
• The seconds-field shift. A six-field expression is 09:30 in Quartz/Spring/Hangfire (leading seconds), but the same string parses to a different — or invalid — schedule in parsers that read a trailing sixth field as a year. Copying expressions between dialects without re-parsing is how jobs silently stop.
• The day-of-week mapping. In Quartz, 1 is Sunday, so 0 9 * * 1-5 that meant Mon–Fri now includes Sunday and excludes Friday.

Step 1 — Check the timezone the scheduler uses

System cron evaluates the expression in the machine's local timezone, which on cloud servers is usually UTC. Confirm what "now" means to the scheduler:

timedatectl            # system timezone
date                   # what "now" means to cron
TZ=Asia/Shanghai date  # what you assume "now" is

Fix options: set CRON=Asia/Shanghai (or CRON_TZ, depending on the cron implementation) at the top of the crontab, or schedule everything in UTC and convert at the presentation layer. GitHub Actions schedules in UTC unless you set the optional timezone: property on the schedule trigger.

Step 2 — Confirm the trigger fired

grep CRON /var/log/syslog | tail        # Debian / Ubuntu
journalctl -u cron --since "1 hour ago" # Debian-family systemd (crond on RHEL)
grep crond /var/log/cron | tail         # RHEL / CentOS

• Trigger lines exist → the schedule works; the command is failing. Go to step 4.
• No trigger lines → check the daemon (systemctl status cron) and what the daemon actually sees: crontab -l for the user table, plus /etc/cron.d/ and /etc/crontab for system entries. A syntax error in one line can make a crontab partially load.

Step 3 — Check the schedule's edge cases

Some "missing" runs are real schedule semantics, not bugs:

• Day-of-month × day-of-week is OR, not AND. In standard cron, when both day fields are restricted (0 9 13 * 5), the job runs on the 13th or any Friday — union, not intersection. This is POSIX behavior and surprises almost everyone once. Migrating to a scheduler that uses AND instead (Hangfire's Cronos is documented as AND) makes the same expression run far less often — check which semantics your scheduler implements before assuming the union.
• February 29 and day-31 expressions simply do not fire in most months.
• DST gaps. A 02:30 schedule does not exist on the spring-forward night in half-year zones — the run is skipped, not delayed.

Step 4 — Reproduce the cron environment

The classic failure: the script runs perfectly in your shell and never from cron. Cron starts sh with a minimal PATH (/usr/bin:/bin), no profile, no nvm/rbenv/pyenv, and no TTY:

# See exactly what cron would resolve
env -i /bin/sh -c 'echo $PATH; which node; which python3'

• Use absolute paths for the interpreter and every file it touches.
• cd inside the wrapper script — relative paths resolve against the user's home under cron, not the script's directory.
• For nvm-managed Node, the crontab line typically needs . $HOME/.nvm/nvm.sh && node … or the real binary path.
• Cron injects only a few variables; anything else (ENV, credentials, LANG) must be set inside the wrapper.

Step 5 — Capture output; never let it vanish

Without redirection, stdout/stderr go to the local mailbox — and with no MTA configured they are discarded. This is the single most common reason jobs "fail silently for months":

0 9 * * * /opt/scripts/myjob.sh >> /tmp/myjob.log 2>&1

(Use a path the job's user can actually write — a user crontab usually cannot create files under /var/log; point it at an app-specific directory you have chown'd.)

Then watch the next run: log created but empty means the wrapper started and the inner command hangs or exits silently — add set -x to trace.

Step 6 — Permissions, locking, and overlap

• Ownership: the job runs as the crontab's owner; a root-owned script in a user crontab fails with Permission denied — visible only in the redirected stderr.
• Access control: cron.allow/cron.deny can silently exclude a user.
• Expired password: an expired account password disables all cron execution for that user on some PAM configurations.
• Overlap: a job slower than its interval stacks runs. Serialize with flock: 0 9 * * * flock -n /tmp/myjob.lock /opt/scripts/myjob.sh.

Step 7 — Platform-specific gotchas

Step 8 — The 60-second sanity sweep

crontab -l | grep -v '^#' | grep -v '^$'   # what is scheduled
systemctl status cron --no-pager | head -3 # is the daemon alive
grep CRON /var/log/syslog | tail -5        # did triggers fire
ls -l /tmp/myjob.log                       # is output being captured

Put the parser in your loop

Most of the chain above reduces to one question: does this expression mean what I think, in this zone, in this dialect? The Utiltown Cron Expression Parser answers it in one paste — plain-English decode, dialect switch, timezone selector, and the next ten run times, all computed locally in the browser.