Cron Parser & Generator

A standard cron expression has five space-separated fields: minute (0–59), hour (0–23), day of month (1–31), month (1–12) and day of week (0–6, where 0 is Sunday; most implementations also accept 7). Each field accepts * for any value, commas for lists (1,15), hyphens for ranges (1-5) and slashes for steps (*/10 means every 10 units). So 0 9 * * 1-5 means 9:00 on weekdays, */5 * * * * means every five minutes, and 0 0 1 * * means midnight on the first of every month. If you enter six fields, the first is treated as seconds, a format common in Node.js schedulers.

This tool translates the expression into plain language and lists the next five actual run times, so you can confirm a schedule before deploying it. The classic mistake is swapping minute and hour: to run daily at 2:30 you need 30 2 * * *, not 2 30 * * * (which is invalid because the hour field stops at 23). Another trap is that steps reset within their unit: */45 * * * * runs at minute 0 and minute 45 of every hour, so the gap is not a constant 45 minutes.

Be careful when you restrict both day of month and day of week. In standard (Vixie) cron, if neither field is *, the job runs when either one matches, not when both do. So 0 0 13 * 5 fires on the 13th of every month and on every Friday, not only on Friday the 13th. Platforms that use Quartz syntax (Java and some cloud services) have seven fields and use ? for "no specific value", which differs from the Unix syntax used here.

Time zones cause more scheduling bugs than anything else. This tool shows upcoming runs in your browser’s time zone, but servers, GitHub Actions and many cloud schedulers default to UTC. For 9:00 in New York during daylight saving time (UTC−4), a UTC scheduler needs 0 13 * * *. Always check the target platform’s time zone before you ship.