A scheduled job can have valid syntax and still run at the wrong time. Before copying an expression into a deployment, check its fields and the clock used by the scheduler. The Cron Parser shows the fields and previews upcoming runs without executing a job.
Check a weekday job
For a job that runs at 09:00 from Monday through Friday, enter:
0 9 * * 1-5The five positions are minute, hour, day of month, month, and day of week. Here, 0 means minute zero, 9 means hour nine, and 1-5 selects weekdays. ByteKiln uses 0 for Sunday through 6 for Saturday. Use this range rather than assuming every scheduler accepts the same aliases or Sunday numbering.
With the starting clock fixed at Wednesday, September 16, 2026, 08:30 in your local timezone, the first three runs are:
2026-09-16 09:00
2026-09-17 09:00
2026-09-18 09:00The browser UI uses the current clock, so a later visit will show later dates. To reproduce these dates in a test, call the same library with an explicit local date:
getNextRuns('0 9 * * 1-5', 3, new Date(2026, 8, 16, 8, 30))JavaScript’s numeric month is zero-based: 8 is September. The preview starts with the next minute after the supplied clock; it does not return the current minute even if that minute matches.
Watch the two day fields
This expression is easy to misread:
0 9 1 * 1It means 09:00 on the first of the month or on Monday, following the Unix rule used by ByteKiln when both day fields are restricted. It does not mean “only on a Monday that is also the first.” Starting at the same September 16 clock, the first three matches are September 21, September 28, and October 1 at 09:00.
The crontab manual describes this day-field behavior. Check your deployment scheduler’s own documentation too: Unix cron, Quartz, and cloud schedulers are not interchangeable dialects.
Compare the scheduler’s timezone
ByteKiln calculates the preview with your browser’s local timezone. There is no timezone selector or remote scheduler connection. A browser set to Asia/Kolkata and a server configured for UTC can interpret the same 9 as different instants.
Record the timezone beside the expression in your configuration review. Then compare the preview with the scheduler’s next-run output. Do not infer daylight-saving behavior from a few ordinary dates: the browser’s date calculations and the production scheduler can handle clock transitions differently.
Know what this check leaves out
The parser defaults to five-field standard cron. A Quartz.NET expression with seconds and a year, or a six-field Hangfire one, needs the matching dialect selected — and Quartz counts day-of-week from 1 = Sunday, so the same number lands on a different day. A syntactically valid schedule does not guarantee that your command exists, has permission to run, or will complete before the next invocation. Logs and an execution test are still needed.
The preview scans at most 600,000 minutes. Very sparse schedules can return fewer dates than requested, and an impossible combination such as February 31 produces no runs within that window. An empty preview is a reason to inspect the date constraints, not proof that the scheduler is broken.
Once the schedule looks right, keep the expression, timezone, and expected next run together in your deployment review. That makes the next debugging session much easier than working backward from a missed job.