"It works when I run it manually, but not on cron" is one of the most common — and most misleading — bug reports in backend work. The script isn't broken. Something about the environment cron runs it in is different from the environment you're testing in.
Why "Works Manually, Fails on Cron" Happens
When you run a command in your terminal, your shell loads your profile (.bashrc, .zshrc, or similar), sets up your PATH, activates any virtual environment you're in, and gives your script access to environment variables you've set. Cron does almost none of this by default. It runs with a minimal, often nearly empty, environment — which is exactly why a script that "just works" for you can fail invisibly on a schedule.
The Real Causes, Ranked by Frequency
1. PATH Doesn't Include What You Expect
If your script calls python3, node, or any command without a full path, cron may not find it — because cron's PATH is much shorter than your interactive shell's PATH. Using the full absolute path to each executable inside the cron command (or at the top of the script) resolves this immediately.
2. Environment Variables Aren't Set
API keys, database URLs, or config values you've exported in your shell profile don't automatically exist under cron. If your script reads from environment variables, either load them explicitly inside the script or source your environment file at the start of the cron command.
3. Virtual Environments Aren't Activated
A Python virtual environment or Node version manager (nvm) active in your terminal isn't active under cron. The cron command needs to explicitly activate it, or call the interpreter's full path inside that environment directly.
4. Wrong Working Directory
Cron doesn't run your script from the directory you'd expect — it typically starts from your home directory or another default. Any relative file paths inside the script (reading a config file, writing a log) can silently fail or write to the wrong place. Use absolute paths, or explicitly cd into the correct directory at the start of the cron command.
5. Silent Failures With No Logging
By default, cron discards a job's output unless you redirect it. If a script fails, you may never see why — it just doesn't produce the expected result, with no error visible anywhere. Redirecting both stdout and stderr to a log file is the single highest-leverage change you can make before debugging further.
A Systematic Debugging Order
Confirm the job is actually scheduled and enabled, check the cron daemon's own log to see if it even attempted to run, add output redirection if it's missing, then compare the exact environment (PATH, env vars, working directory) between your manual run and what cron actually has available. In nearly every case, the fix is an environment mismatch, not a bug in the underlying logic.
Frequently Asked Questions
Almost always an environment difference — cron runs with a minimal environment that doesn't include your shell's PATH additions, environment variables, or active virtual environments. Using absolute paths and explicitly loading required environment variables inside the cron command usually resolves it.
Redirect its output to a log file in the crontab entry (e.g. >> /path/to/log 2>&1) and check the cron daemon's own system log (/var/log/cron or /var/log/syslog) to confirm it attempted to run at all.
Yes — by default cron discards output entirely unless you redirect it, so a script that errors out or exits early can leave no visible trace. Adding explicit logging is the first fix, before trying to diagnose anything else.
Cron Job Still Not Cooperating?
I debug failing scheduled tasks and cron jobs — whether it's a syntax issue, an environment problem, or a silent failure with no error logged. Get a free audit to find the actual cause.
Let's Solve Your Problem → View Upwork Profile