Predicting Cron Run Times: From Expression to Timestamps

You inherit a server job scheduled with */15 9-17 * * 1-5. The syntax checks out, but a question remains: when, exactly, does it fire? A cron expression is a description, not a date — this article walks through how a calculator turns that description into concrete timestamps, and the details that quietly change the answer.

From expression to timestamps

The conversion is a scan, not a formula. The five fields — minute, hour, day-of-month, month, weekday — are each parsed into a set of allowed values: * allows everything, 9-17 a range, */15 every 15th value, and comma lists like 1,15 combine picks. The calculator then starts one minute after your reference time and steps forward minute by minute, keeping every moment where all five sets match at once, until it has the next N hits.

Worked example: */15 9-17 * * 1-5 from Monday 2026-10-26 10:07 UTC. The minute set is every 15th minute, the hour set is 9 through 17, and weekdays are Monday through Friday. The next matching instants:

2026-10-26T10:15:00Z
2026-10-26T10:30:00Z
2026-10-26T10:45:00Z
2026-10-26T11:00:00Z

Notice the first run is 10:15, not 10:07 — the reference time itself never counts, because a schedule fires at matching minutes, and 10:07 is not one of them.

Everything is computed in UTC

The output timestamps are UTC, on purpose. Servers mostly run cron in UTC (or behave inconsistently across daylight-saving shifts otherwise), so a predictable common ground avoids the classic "it ran an hour early in March" mystery. 0 9 * * 1-5 evaluated from a Saturday becomes 2026-10-26T09:00:00Z — Monday morning, nine o'clock, UTC. If your machine or scheduler runs in local time, translate before comparing: that 09:00 UTC is 05:00 in New York in October but 04:00 during standard-time months. When in doubt, check what your crontab's CRON_TZ or system zone actually is.

The day-of-month and day-of-week subtlety

One field pairing deserves special care. Classic Vixie cron treats a restricted day-of-month and a restricted day-of-week with an OR: 0 0 1 * 1 means "the 1st or any Monday". This calculator instead requires both fields to match. Run 0 0 1 * 1 and the results are 2027-02-01 and 2027-03-01 — the first dates that are simultaneously the 1st of a month and a Monday. Neither interpretation is "wrong"; they are different conventions, and the mismatch is a real source of surprise when you verify a production schedule. The (much deeper) grammar behind these fields lives in How Cron Expressions Work.

Broken schedules announce themselves

Ask for the next run of 0 0 30 2 * — 00:30 on February 30th — and no date ever matches. The calculator scans up to two years of minutes per requested run and then reports that it could not find enough runs, which is exactly the diagnosis you want before a job silently never fires. The same scan exposes subtler traps: 0 0 29 2 * matches only in leap years, so the next hit is 2028-02-29, and a comma list like 30 4 1,15 * * correctly yields the 1st and 15th of each month at 04:30 UTC (Nov 1, Nov 15, Dec 1…). Weekdays accept both 0 and 7 for Sunday, so * * * * 7 behaves identically to * * * * 0.

Why predicting beats guessing

Reading an expression in your head works for simple cases and fails exactly when it matters: overlapping ranges, weekday windows, month boundaries. Generating the next N timestamps turns a hunch into a list you can diff against expectations — before the deploy, not after the 3 a.m. page. It also doubles as documentation: a schedule expressed as "Nov 1, Nov 15 at 04:30 UTC" is far harder to misread than its five fields.

Try it yourself

Project any five-field expression into real timestamps with the Cron Next Run Calculator — start with */15 9-17 * * 1-5 and check the first hit lands on a 15-minute boundary. Building an expression from a plain-English schedule is the reverse direction, covered by the Cron Expression Generator. To translate UTC results into your own wall-clock time, the Time Zone Converter does the offset math for you.