Cron schedules: seven mistakes that run jobs at the wrong time
A cron expression that is valid is not always one that does what you meant. These are the mistakes that cause jobs to run at the wrong hour, on the wrong day, or far more often than planned.
Last reviewed 2026-11-01. Platform rules are summarized from each platform's documentation, linked below and checked on the date shown. Where a platform has added options recently, check its page.
Reading the five fields
A Unix cron expression has five fields: minute, hour, day of month, month and day of week. 30 9 * * 1-5 means minute 30, hour 9, any day of the month, any month, Monday to Friday: 09:30 on weekdays. A star means every value, a slash gives a step (*/15 is every 15 units), a comma lists values and a hyphen gives a range.
Mistake 1: forgetting the time zone
Cron has no built-in idea of your time zone. Unix cron uses the system time zone of the host. A Kubernetes CronJob uses the time zone of the controller unless you set .spec.timeZone, which has been available since Kubernetes 1.27. GitHub Actions scheduled workflows run in UTC by default, and the workflow can set an IANA time zone string to change that; AWS EventBridge cron rules run in UTC. A job meant for 09:00 in New York is 0 14 * * * in UTC in winter and 0 13 * * * in summer, and a UTC schedule does not follow daylight saving time. The dialect tool above shows GitHub Actions and EventBridge runs in UTC. Choose the platform in the tool above and switch between UTC and local time to see the next runs.
Mistake 2: restricting both day fields
In Unix cron, if both day of month and day of week are restricted (neither is a star), the job runs when either matches. 0 0 13 * 5 runs on every 13th and on every Friday, not only on Friday the 13th. If you want the intersection, schedule the earlier of the two and test the other condition inside the job.
Mistake 3: copying Unix cron into EventBridge
AWS EventBridge cron has six fields, with a year at the end. It requires a question mark in either the day of month or the day of week field, and it numbers days of the week from 1 (Sunday) to 7 (Saturday), or lets you use names such as MON-FRI. A Unix 30 9 * * 1-5 is written cron(30 9 ? * MON-FRI *); pasting numbers across shifts the job by one day. The conversion box in the tool shows the EventBridge form of a Unix schedule.
Mistake 4: expecting GitHub Actions to be exact
GitHub Actions runs scheduled workflows no more often than every five minutes. GitHub documents that scheduled runs can be delayed at times of high load, such as the start of the hour, so a job at minute 0 may start late. Pick an off-peak minute such as 17 for work that does not need to start on the dot. Scheduled workflows also run only on the default branch.
Mistake 5: a step that does not divide evenly
A step restarts at the beginning of each range. */7 in the minute field runs at minutes 0, 7, 14, 21, 28, 35, 42, 49 and 56, then again at 0 of the next hour, so the gap after 56 is only four minutes. For intervals that do not divide 60 or 24, use a different mechanism, such as a job that reschedules itself.
Mistake 6: overlapping runs
If a run takes longer than the interval, the next one can start while the last is still going. Kubernetes lets you set a concurrencyPolicy of Allow, Forbid or Replace for CronJobs. For other platforms, take a lock inside the job, or make the work safe to run twice.
Mistake 7: not looking at the next runs
The cheapest test is to list the next five run times before you deploy. If they are not the times you pictured, the expression is wrong, whatever it says. The cron explainer turns an expression into a plain-English sentence, and the dialect checker shows the runs and what each platform would reject.
A checklist before you ship
- Write down the time zone the schedule is in, in the comment next to it.
- Check day of month and day of week are not both restricted unless you want "either".
- Run the expression through the dialect of the platform that will use it.
- Make the job safe to run twice and safe to start late.
- Alert when the job has not run, not only when it fails.
Frequently asked questions
What does 0 0 * * * mean?
Minute 0 of hour 0 on every day: midnight, every day, in the time zone of the platform.
Does cron handle daylight saving time?
Not consistently. A schedule in a time zone with daylight saving time can skip or repeat a run on the change days, depending on the implementation. UTC schedules avoid the problem.
Can cron run every 30 seconds?
Not in five field cron, whose smallest unit is a minute. Use a long-running process or a scheduler with second resolution.
Sources
- crontab(5) manual page checked 2026-11-01
- Kubernetes: CronJob checked 2026-11-01
- GitHub Docs: Events that trigger workflows (schedule) checked 2026-11-01
- AWS EventBridge: Schedule expressions for rules checked 2026-11-01