5 Reasons Your Cron Job Silently Didn't Run (and How to Check)

It's 9am and your database backup should have run at 2am. You open the server, check the backup directory — empty. No error email, no alert, just silence. You run crontab -l, and the entry is right there, exactly as you wrote it. The job looks perfect. It just didn't happen. If you've been here, you know the worst part of cron isn't that jobs fail — it's that they fail quietly, and there are five completely ordinary reasons.

1. The Environment Isn't Yours

When cron runs a job, it runs it with a minimal environment — a bare PATH, no shell profile, no aliases. The script that works in your terminal calling node or docker fails under cron with a silent "command not found" because the binary isn't on cron's path. Fix: use absolute paths in the script, or set PATH at the top of the crontab.

2. You're Editing the Wrong Table

There are two kinds of crontab. crontab -e edits your user's table, where jobs run as you. System jobs live in /etc/crontab and require a user field before the command. It's easy to add a system-style entry to your user crontab — or a user-style entry to the system file — and have it ignored or run as the wrong account. Check who the job runs as, not just whether the text is present.

3. The Schedule Means Something Else

Cron syntax has traps. The big one: when you set both a day-of-month and a day-of-week, cron runs the job on either — not both. 0 2 15 * 1 runs at 2am on the 15th and every Monday, not "the Monday that is the 15th." Paste the expression into the cron parser and look at the next five computed run times — a 5-second check that catches the trap instantly.

4. The Job Ran, but Output Vanished

Nothing set MAILTO, so the job's stdout went nowhere. The script exited nonzero, and nobody saw it. This is the most common silent failure of all: the job ran fine, the command inside it failed, and the failure was swallowed. Redirect output to a file, or set MAILTO, so a failure produces a trace you can actually read.

5. The Clock Isn't What You Think

Cron uses the system timezone — which on many VPS images is UTC. Your "2am" was 2am UTC, not your local time. And around daylight saving, an hour can vanish entirely. The unix timestamp shows what the machine actually thinks the time is, and it's the fastest way to confirm the server's clock disagrees with your intention. When you're checking whether a pattern matches, the regex tester handles the input-validation half of the job, but cron's time semantics are its own trap.

We compared cron to systemd timers in our guide to cron vs systemd timers. The silent failures above are cron-specific — systemd logs loudly, which is half the reason people switch. Check the path, the user, the schedule, the output, and the clock — and your backups will start running on time.