Cron Next-N Runs
Compute the next N UTC firings of a cron expression from a start date.
Overview
Enter a cron expression and a start date, and the tool lists the next N UTC firings - the actual timestamps your job would execute at. Useful when "every 15 minutes Mon-Fri 9-5" is correct on paper but you want to see five concrete examples before pushing the schedule live.
This is for developers who've ever pushed a cron change and then nervously watched the clock. Reach for it when validating a non-obvious schedule (last Friday of each month, every other hour), aligning multiple jobs that should not overlap, or producing a runbook entry showing "you should see this job at 14:00, 14:15, 14:30..."
How it works
The schedule is parsed against the standard 5-field Unix cron grammar (minute / hour / day-of-month / month / day-of-week), supporting lists, ranges, steps, and named values. To compute each next firing, the algorithm walks forward from the start time minute by minute (with efficient skipping based on the most-constrained field) and returns the first N matches.
All results are emitted in UTC to avoid daylight-savings confusion - if your cron runs on a server in local time, mentally shift the output. Day-of-month and day-of-week use cron's OR semantics when both are restricted.
Examples
- Every weekday at 09:00, starting Jan 1 2026:
Expression: 0 9 * * 1-5 Start: 2026-01-01T00:00:00Z Next 3: 2026-01-01T09:00Z 2026-01-02T09:00Z 2026-01-05T09:00Z - Every 15 minutes, next 4:
Expression: */15 * * * * Next 4: 14:00, 14:15, 14:30, 14:45 - First of every month at midnight:
Expression: 0 0 1 * * Next 3: Feb 1, Mar 1, Apr 1 - Sundays only:
Expression: 0 12 * * 0 Next 2: 2026-05-24T12:00Z, 2026-05-31T12:00Z
FAQ
Why UTC and not my local time?
UTC avoids the DST surprises that bite scheduled jobs twice a year. Cloud schedulers (EventBridge, Cloud Scheduler) also run in UTC by default.
How is the "next" firing defined when the start time exactly matches?
The algorithm advances by one minute before checking, so the start time itself is excluded. The first result is always strictly after the start.
Does it handle L (last day of month) or # (nth weekday)?
Those are Quartz/Spring extensions, not standard Unix cron. The plain cron parser here doesn't recognise them - use the Quartz converter first if your expression uses those tokens.
What if my expression never fires?
If you've written something impossible like 0 0 30 2 * (Feb 30), no dates will appear. Double-check field combinations - cron silently produces no firings for invalid date combinations.