Five Vixie fields, not Quartz
I paste a cron string here before I put it on a box that will page me. Classic Unix/Vixie crontab is five fields: minute, hour, day-of-month, month, day-of-week. This page accepts exactly those five. Quartz (Java, many Spring @Scheduled jobs) is six or seven: seconds first, optional year last, and ? instead of * in one of the day fields. Kubernetes CronJob is Vixie-shaped (five). GitHub Actions schedule is five but always UTC. If you copy a Quartz sample that starts with 0 0 9 ? * MON-FRI into this box, it should refuse — six tokens, plus a question mark this parser does not speak.
The useful output is the field-by-field English. The “next five run times” list is a coarse sketch (day-stepped from now), not a full crontab simulator. Confirm against crontab -l, the CronJob controller, or systemd timers before you trust a 3am fire. Timezone is the server’s TZ, not this laptop’s, unless they happen to match.
Worked example: weekdays at 09:00 IST
0 9 * * 1-5 means minute 0, hour 9, every day-of-month, every month, Monday through Friday. In Vixie, 0 is Sunday and 1 is Monday, so 1-5 is weekday in the US sense and in India too. On a container whose TZ is Asia/Kolkata that is 9:00 IST. Same string on a UTC CronJob is 9:00 UTC, which is 14:30 IST — payroll Slack at lunch, not at open. People write 0 9 * * 1-5 on a laptop in Pune, deploy to EKS with UTC, and spend a morning calling it a Kubernetes bug.
Worked example: every 15 minutes versus hourly
*/15 * * * * is every 15 minutes, all day: 00, 15, 30, 45. 0 * * * * is once per hour at minute 0. */1 * * * * is every minute, which is what you get when you meant hourly and copied a “every 1 unit” example. I have seen a GST IRN retry job set to * * * * * (every minute) instead of */10 * * * *, then NIC rate-limits, then a “the API is down” war room. Step expressions only apply to the field they sit in. 0 */2 * * * is every two hours at minute 0, not every two minutes.
Worked example: first of the month, and the DOM/DOW trap
0 0 1 * * is midnight on day-of-month 1. In IST that is 00:00 on the 1st; in UTC it is 05:30 IST on the 1st. Vixie’s nasty corner: if you set both day-of-month and day-of-week (e.g. 0 9 1 * 1), many crons fire when either matches — the 1st or Mondays — not “Mondays that are the 1st.” Quartz uses ? to say “no opinion” on one of those fields. This visualizer will not save you from that dialect difference; it will just describe each field. If you needed “first Monday,” you want a different scheduler or a small script, not a cute five-field poem.
DST, seconds, and other ways to get paged
India has no DST. A job on America/New_York can skip or double around the spring-forward and fall-back. AWS CloudWatch cron and EventBridge use UTC and their own six-or-more field quirks — read that console, not this page. Seconds are not a Vixie field; 0 0 9 * * * is Quartz “9:00:00,” and here it is simply invalid. @daily and @hourly nicknames are systemd/cron extensions this parser does not expand. Two controllers scheduling the same string (CronJob plus an in-process node-cron) is how duplicate invoices are born.
Questions
Why did 0 0 9 ? * MON-FRI fail?
That is Quartz: seconds, then five fields, plus ?. This page wants Vixie five: 0 9 * * 1-5 for weekdays at 09:00.
Is Kubernetes CronJob five fields or six?
Five, Vixie-shaped, and the controller runs UTC unless you set timeZone on a recent CronJob spec. Confirm the pod TZ separately.
Does 1-5 mean Monday–Friday?
In Vixie, 0 or 7 is Sunday, 1 is Monday, so 1-5 is Mon–Fri. Quartz often uses MON-FRI names. Do not mix.
If I set day-of-month and day-of-week, is that AND or OR?
Classic Vixie is OR — either field matching can fire. Quartz forbids * on both and uses ? on one. This is a common silent over-fire.
Are the “next run” times a full simulator?
No. They are a coarse sketch. Trust the English breakdown, then verify on the machine that actually runs cron.
My laptop is IST; the cluster is UTC. Who wins?
The cluster. 0 9 * * * is 14:30 IST if the job is UTC. Set TZ explicitly or convert before you paste.