Updated May 2026 · 6 min read
You wrote the expression, deployed the job, and... nothing happened. Your cron job is not running and there are no errors in the logs. This is one of the most frustrating debugging experiences because cron failures are almost always silent.
Here are the 8 most common causes, ordered from most to least frequent, based on real questions from r/sysadmin, r/devops, and Stack Overflow.
This is the #1 cause. You write 0 9 * * * expecting 9am your local time, but the server runs in UTC. Your job fires at 9am UTC — which might be 1am or 4am in your timezone.
Platforms affected: GitHub Actions (UTC only), AWS EventBridge (UTC only), Vercel (UTC only). Linux crontab and Kubernetes v1.27+ let you set a timezone.
Fix: Always convert to UTC explicitly. Use TZ=America/New_York on Linux, or timeZone: America/New_York in Kubernetes CronJob spec.
Linux crontab uses 0=Sunday (or 7=Sunday). Quartz and Spring use 1=Sunday, 2=Monday. If you set 5 for Friday on Linux, it works. On Quartz, 5 means Thursday.
Fix: Use 3-letter abbreviations (MON, FRI) when the platform supports them — they are unambiguous.
Some platforms silently reject or throttle cron jobs below their minimum interval:
*/1 * * * * is accepted but only fires every ~5 minFix: Check your plan limits before deploying. Our validator warns about these automatically.
AWS EventBridge (and Quartz) require a ? in either day-of-month or day-of-week. Using * in both is an error — but on Linux it is perfectly valid.
Fix: If you target AWS, replace the unused field with ?. Example: 0 9 * * ? (every day at 9am, day-of-week ignored).
A job scheduled at 2:30am might run twice during fall-back or skip entirely during spring-forward, depending on how the platform handles timezone transitions.
Fix: Schedule critical jobs at times that are not affected by DST (e.g., 4am or noon). Or use UTC-only platforms.
0 0 31 2 * (February 31st) is syntactically valid on most platforms but will never fire. The system accepts it without warning.
Fix: Test your expression with a next-run previewer to verify it actually produces future dates.
On Linux, cron runs with a minimal environment. Your script might rely on PATH entries, environment variables, or file permissions that are set in your interactive shell but not in cron.
Fix: Use absolute paths in your cron command. Set PATH=/usr/local/bin:/usr/bin:/bin at the top of your crontab. Check that the script has execute permissions.
On Linux servers, the cron daemon (crond or cron) might be stopped or disabled. Docker containers often do not include a cron daemon by default.
Fix: Run systemctl status cron (or service cron status) to verify. In Docker, install and start cron explicitly or use the platform's native scheduler.
Paste your expression into our cron explainer to see exactly what it means, or use the cross-platform validator to check if your syntax is correct for your target platform.
If you want to get alerted when your cron jobs miss their schedule, join the waitlist for cronwiz AI Cron Monitoring — launching Q3 2026 at $5/month.