Cron Next Run Previewer | See the Next 10 Fire Times Before You Deploy
Type a cron expression and get the next 10 execution times laid out by time zone. The five fields are broken out and a plain-language summary sits beside them, so you can see exactly when your schedule fires.
💡 About this tool
A cron string like */15 * * * * is dense, and "when does it actually run next?" is hard to answer in your head. Expressions such as 0 9 1-7 * * (9 AM on the 1st–7th of the month) or 30 2 * * 0 (Sunday at 2:30 AM) force you to walk a mental calendar to be sure.
This tool answers the question directly: as soon as you type a valid expression, it lists the next 10 fire times as real timestamps. It walks the schedule minute by minute inside your browser, so a tight */15 and a yearly 0 0 1 1 * both preview the same way. Switch the time zone and you can see what a UTC-authored expression means in Tokyo, London, or New York without doing the offset math yourself.
🧐 Frequently Asked Questions
Q. What happens when I set both day-of-month and day-of-week?
In standard Unix cron (Vixie cron), if both fields are anything other than *, the job runs when either matches — an OR, not an AND. So 0 0 15 * 5 fires on the 15th of every month and on every Friday. This previewer uses the same OR rule, so the list shows you the real fire days.
Q. How are weekdays numbered? 0 is Sunday, 1 is Monday, ..., 6 is Saturday. Some systems also accept 7 as Sunday; this tool evaluates the 0–6 range.
Q. Which syntax is supported?
Five forms: * (all), a single value, A-B (range), A,B,C (list), and */N (step). Combinations like 0-30/5 are parsed too.
Q. Can I use a seconds field? It handles the standard five fields (minute, hour, day, month, weekday). Six-field formats with a seconds column (such as Quartz) are not supported.
Q. Why does the list sometimes come back empty?
An impossible date such as 0 0 30 2 * (February 30) has no matching day within the next two years, so the result is empty by design.
📚 Why time zones trip up cron
Cron runs in the host's system time zone by default. Cloud instances usually default to UTC, so 0 9 * * * on a fresh server does not mean 9 AM where you live. The common advice is to keep servers on UTC and convert to local time at the application layer, which keeps schedules predictable.
Daylight saving time is the other classic trap. When clocks spring forward, the skipped hour means a 2:30 AM job can vanish for that day; when they fall back, a job can run twice. Picking a zone without DST, such as Asia/Tokyo, removes that ambiguity from your preview entirely.