Cron Not Working? A Debugging Checklist for Every Platform

Updated May 2026 · 7 min read

When cron is not working, the symptoms are always the same: nothing happens, and there are no useful error messages. But the root cause is different depending on your platform.

This guide is a structured debugging checklist. Jump to your platform or read through all of them.

Linux Crontab

1. Is the cron daemon running?
   Run systemctl status cron. If stopped, start it with systemctl start cron.
2. Is the syntax valid?
   Paste your expression into our validator. Even one extra space can break it.
3. Check the logs.
   grep CRON /var/log/syslog (Debian/Ubuntu) or journalctl -u cron (systemd). If no entries appear at the expected time, the expression itself is the issue.
4. Does the script run manually?
   Run it by hand: /bin/bash /path/to/script.sh. If it fails, fix the script before blaming cron.
5. PATH and environment.
   Cron runs with minimal PATH. Use absolute paths everywhere. Add PATH=/usr/local/bin:/usr/bin:/bin at the top of your crontab.
6. Output redirection.
   Add >> /tmp/cron.log 2>&1 to your cron command to capture errors.

AWS EventBridge (CloudWatch Events)

1. Is it a 6-field expression?
   AWS uses min hour dom month dow year. A 5-field Linux expression will be rejected or misinterpreted.
2. Did you use ? correctly?
   AWS requires ? in either day-of-month or day-of-week. Using * in both is an error.
3. Everything is UTC.
   AWS EventBridge does not support timezones. If your rule says 9:00, it means 9:00 UTC. Period.
4. Is the rule enabled?
   Check the rule state in the EventBridge console. Rules can be disabled without deletion.
5. Check target permissions.
   The rule might fire but the target (Lambda, SQS, etc.) might not have the right IAM permissions to execute.

Kubernetes CronJob

1. Check CronJob status.
   kubectl get cronjob <name> — look at the LAST SCHEDULE and ACTIVE columns.
2. Is the job suspended?
   Check spec.suspend. If true, the CronJob exists but never creates Jobs.
3. timeZone requires v1.27+.
   If you set timeZone: America/New_York on an older cluster, it is silently ignored and the job runs in UTC.
4. Container image pull errors.
   kubectl describe job <job-name> — look for ImagePullBackOff or CrashLoopBackOff.
5. Concurrency policy.
   If set to Forbid and a previous run is still active, new runs are skipped silently.

GitHub Actions

1. UTC only.
   GitHub Actions schedule always runs in UTC. There is no timezone setting.
2. 5-minute minimum, plus jitter.
   Jobs can be delayed 5-30 minutes under load. If your workflow requires precise timing, GitHub Actions is not the right tool.
3. Disabled after 60 days of inactivity.
   If the repository has no commits or activity for 60 days, scheduled workflows are automatically disabled.
4. Must be on default branch.
   Schedule triggers only work on the default branch (usually main). A schedule in a feature branch does nothing.

Vercel Cron

1. Check your plan.
   Hobby: 1 cron/day max. Pro: 1-min minimum interval.
2. vercel.json must be correct.
   Cron jobs are defined in vercel.json under crons. Syntax errors in the file silently disable cron.
3. UTC only.
   Vercel cron runs in UTC. No timezone support.
4. Function timeout.
   The API route invoked by the cron must complete within the function timeout (Hobby: 10s, Pro: 60s).

Universal Debugging Steps

Regardless of platform:

1. Explain the expression — make sure it means what you think
2. Preview the next 10 runs — confirm the dates make sense
3. Validate across platforms — catch syntax differences
4. Check logs for silent failures (permission, network, timeout)
5. Simplify first: test with * * * * * to confirm the mechanism works, then refine

Want automated monitoring for all your cron jobs? Join the cronwiz waitlist — we are building AI-powered cron monitoring that alerts you in plain English when jobs miss, fail, or slow down.