Cron Next-Fire Times
Given a cron expression, list the next 10 fire times in UTC.
Overview
The Cron Next-Fire Times tool takes a cron expression and lists the next ten moments it will trigger, all expressed in UTC. Paste a schedule like */15 * * * * or 0 9 * * 1-5 and the tool walks the calendar forward from the current instant, giving you a quick sanity check that the expression really means what you think it does.
Useful for DevOps engineers verifying a Kubernetes CronJob, data engineers scheduling Airflow DAGs, sysadmins reviewing /etc/crontab, and anyone debugging a "this job fired at the wrong hour" incident before pushing the change to production.
How it works
The parser supports the classic five-field cron syntax (minute, hour, day-of-month, month, day-of-week) along with step values (*/5), ranges (1-10), lists (1,15,30), and standard day-of-week names. It applies the POSIX rule that when both day-of-month and day-of-week are restricted, the job fires when either matches — a subtle gotcha that catches a lot of teams.
Each fire time is computed by advancing minute-by-minute through the calendar in UTC, skipping fields that do not match, so the tool reports the same moments your cron daemon will see assuming the daemon also runs in UTC. Servers that run in a local zone need to apply the zone offset manually.
Examples
*/15 * * * * → every quarter past the hour
0 9 * * 1-5 → 09:00 UTC every weekday
0 0 1 * * → midnight UTC on the 1st of each month
15 14 * * 1,3,5 → 14:15 UTC Mon/Wed/Fri
FAQ
Why UTC instead of my local zone?
Most server cron daemons run in UTC by default, and UTC removes the ambiguity around daylight-saving transitions where a local-time schedule can fire twice or skip a slot.
Does it support seconds or year fields?
The classic five-field syntax is parsed. Extended Quartz-style expressions with seconds and year fields are not.
What if day-of-month and day-of-week are both set?
It fires when either field matches, matching POSIX cron behaviour. Vixie cron has the same rule. This is a frequent source of confusion when porting schedules to systems that AND the two fields.
Are @hourly, @daily, and @reboot shortcuts supported?
The named shortcuts @hourly, @daily, @weekly, @monthly, and @yearly expand to their five-field equivalents. @reboot is not a schedulable moment so it is skipped.
Why are some lists out of order in the output?
The next-fire list is always in chronological order. If your expression has multiple fields with lists, the tool combines them and sorts the results before display.