TL;DR

A cron job that silently fails to run is one of the most frustrating issues to debug because there is no immediate error — the job simply does not execute. By the time you notice, queued work has piled up and data is stale.

Diagnosis workflow

Verify the cron daemon is running:

systemctl status cron

List the current user's crontab:

crontab -l

Check system-wide cron jobs:

ls -la /etc/cron.d/
cat /etc/crontab

Look at cron logs for execution records:

grep CRON /var/log/syslog | tail -30

Common causes

PATH issues: Cron runs with a minimal PATH (/usr/bin:/bin). Commands that work in your shell may not be found by cron.

Fix by specifying full paths:

# Fails — 'php' not in cron's PATH
* * * * * php /var/www/myapp/artisan schedule:run

# Works — absolute path
* * * * * /usr/bin/php /var/www/myapp/artisan schedule:run >> /var/log/cron-laravel.log 2>&1

Environment variables: Cron does not load your shell profile. If your job needs environment variables, source them explicitly:

* * * * * cd /var/www/myapp && source .env && /usr/bin/php artisan schedule:run

Permission issues: The crontab file must be owned by the correct user, and the script must be executable.

Syntax errors: A single syntax error in a crontab file silently disables all jobs below it. Validate with crontab -e and check for missing newlines at the end of the file.

Monitoring cron execution

Always redirect output so you can see errors:

0 2 * * * /path/to/script.sh >> /var/log/myjob.log 2>&1

Use a dead-man's-switch monitoring service — if the job does not check in by its expected time, you get alerted.

Where Reflex helps

Reflex monitors scheduled task execution through expected-run-time windows. If a cron job fails to execute or returns a non-zero exit code, Reflex alerts your team and can attempt to re-run the job, providing the output and exit code in the incident timeline. See How it works.