Cron jobs that silently don't run in WSL2: common causes and how to check
A cron job that "should" work but never actually runs, with no error anywhere, is one of the most frustrating classes of bug — there's no crash, no log by default, just silence. Three causes account for most of it, especially on WSL2.
Cause 1: relative paths in the crontab entry
This one is easy to write by accident and easy to miss, because it looks correct:
0 20 * * * /home/user/.venv/bin/python paper_trader.py >> /home/user/logs/cron.log 2>&1
That fails silently because cron does not run your script from the directory it lives in —
it runs from your home directory by default, with a minimal PATH and no knowledge of
where paper_trader.py actually is. The interpreter (/home/user/.venv/bin/python) is a
full path and runs fine; it just immediately fails to find the script and exits, and
because the crontab line redirects both stdout and stderr to a log file, you might assume
silence in that log means success rather than "cron itself never got far enough to write
anything." Fix: always use the full path to the script, not just the interpreter:
0 20 * * * /home/user/.venv/bin/python /home/user/project/src/paper_trader.py >> /home/user/logs/cron.log 2>&1
Cause 2: WSL2 isn't running when cron would have fired
Cron only runs while its host is running. WSL2 does not start automatically when
Windows boots — it only starts when something launches it (opening a terminal, a Windows
Scheduled Task with wsl.exe, etc.). If the distro wasn't running at 20:00, that day's job
was never scheduled, not "failed" — cron doesn't queue up or catch up missed runs.
Cause 3: cron's own service isn't enabled
Less common but worth ruling out first since it takes ten seconds:
systemctl status cron
Look for Active: active (running). If it says inactive or the unit doesn't exist,
nothing you put in crontab will ever fire, regardless of the other two issues.
How to actually check, in order
systemctl status cron— is the service itself running?crontab -l— is the entry there, and does it use full paths for every file argument, not just the interpreter?- Run the exact crontab command by hand from your home directory (
cd ~ && <paste the command>) — this reproduces cron's minimal environment far better than running it from inside the project folder, and will surface path problems immediately. - Check whether the host (WSL2, in this case) was actually running at the scheduled time.
Sources: man 5 crontab (working directory and environment behavior); man 8 cron;
verified directly against a real recurring-job bug that hit all of cause 1 and cause 2 in
combination while building this project's automation.