Cron Jobs
debt(d7/e3/b5/t7)
Closest to 'only careful code review or runtime testing' (d7). Cron job misconfigurations (wrong PATH, missing output redirect, overlapping executions) are not caught by any automated tool in the detection_hints — tools like crontab, crunz, and laravel-scheduler are management tools, not static analyzers. Problems surface only when jobs silently fail in production or overlap, requiring manual review or runtime observation to detect.
Closest to 'simple parameterised fix' (e3). The quick_fix suggests straightforward fixes: add MAILTO='', redirect output to log files, use absolute paths. Each fix is localized to the crontab or job script. However, retrofitting overlap prevention (file locking) or switching to a scheduler framework touches multiple files, pushing slightly above e1.
Closest to 'persistent productivity tax' (b5). Cron jobs apply only to CLI context but affect ongoing operations: every new scheduled task must follow the same conventions (absolute paths, logging, locking). A poorly designed cron setup decays over time as jobs accumulate without monitoring. It's not architectural-level burden but imposes a persistent operational tax on the team.
Closest to 'serious trap' (t7). The misconception explicitly states developers assume cron runs in the same environment as their shell — it doesn't. This contradicts how interactive shells work, where relative paths and typical PATH settings function normally. The 'obvious' way (using 'php script.php' without absolute paths) fails silently, matching t7's 'contradicts how a similar concept works elsewhere.'
Also Known As
TL;DR
Explanation
Cron syntax: five fields (minute hour day month weekday) followed by the command. Special strings (@hourly, @daily, @weekly, @monthly, @reboot) simplify common schedules. Cron runs in a minimal environment — PATH is different from interactive shells, so use absolute paths. Output goes to the user's email unless redirected. PHP cron jobs should use the CLI SAPI, not the web server. Consider systemd timers or a task scheduler like Laravel Scheduler for more complex needs.
Diagram
flowchart LR
CRON[cron daemon] -->|reads| CRONTAB[crontab -e]
CRONTAB --> SYNTAX[minute hour day month weekday command]
subgraph Examples
EV_MIN[every minute: * * * * *]
EV_HOUR[every hour: 0 * * * *]
EV_DAY[daily 2am: 0 2 * * *]
EV_WEEK[weekly Mon: 0 0 * * 1]
end
CRON --> EXEC[Execute command]
EXEC -->|stdout| MAIL[Email to user<br/>or redirect to log]
subgraph Issues
OVERLAP[Job overlaps<br/>previous still running]
ENV2[Wrong environment<br/>PATH not set]
OVERLAP & ENV2 -->|fix with| LOCKFILE[flock or systemd timers]
end
style EXEC fill:#238636,color:#fff
style OVERLAP fill:#f85149,color:#fff
style LOCKFILE fill:#1f6feb,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Using relative paths — cron's PATH does not include /usr/local/bin; use /usr/bin/php explicitly.
- Not redirecting output — all stdout/stderr goes to cron email which is often unmonitored.
- Overlapping executions — a slow job runs again before the previous one completes; use file locking.
- Running cron jobs as root when a less privileged user is sufficient.
Code Examples
# Broken cron — relative path, no output handling:
*/5 * * * * php /var/www/app/artisan schedule:run
# Fails silently: 'php' not found in cron PATH
# No output captured — errors invisible# Correct cron entry:
*/5 * * * * /usr/bin/php /var/www/app/artisan schedule:run \
>> /var/log/app/schedule.log 2>&1
# With flock to prevent overlap:
*/5 * * * * flock -n /tmp/schedule.lock \
/usr/bin/php /var/www/app/artisan schedule:run >> /var/log/app/schedule.log 2>&1