Cron Calculator🔒 100% local
Cron expression helper. Privacy-first, no server uploads, no tracking.
Related Tools
Parses a five-field cron expression into the concrete schedule behind it: which minutes, hours, days of the month, months and weekdays it expands to (with step, range and list syntax resolved), how many runs that gives per day and per month, the interval between consecutive runs, and the next six fire times in UTC. Weekday and month names are understood where cron allows them, so mon-fri and jan-dec work. Nothing is executed - the expansion and the clock stepping happen in the page, which matters when the expression belongs to an internal job.
How to use it
- Paste the five-field expression, for example 0 9 * * *.
- Press Process.
- Read the per-field expansion first, then the activity counts, then the next six fire times.
Worked example
0 9 * * *becomesCron: 0 9 * * *
0 9 * * *
min hr dom mon dow
Field breakdown:
minute 0 1 value [0-59] 0
hour 9 1 value [0-23] 9
day-of-month * 31 values [1-31]
month * 12 values [1-12]
day-of-week * 7 values [0-7 (0=Sun)]
Calculated activity:
Fires per day (max): 1
Distinct day slots: 31 day(s) x 12 month(s)
Max fires per month: 31 (31 active day(s) x 1 run(s))
Interval between runs: 1440 min (regular)
Next 6 fire times (UTC):
2026-09-27 09:00 Sun
2026-09-28 09:00 Mon
2026-09-29 09:00 Tue
2026-09-30 09:00 Wed
2026-10-01 09:00 Thu
2026-10-02 09:00 Fri
Verify on a real crontab with: crontab.guru or run "date" inside the cron job once to confirm the timezone (cron uses the server local time, not UTC).The next-run list is generated by advancing a clock minute by minute from the moment you press Process, so your six times will start later than these. They were generated with the clock at 2026-09-27 08:00 UTC. Note the times are printed in UTC, while cron itself fires on server local time.
When to use it
- Checking a schedule written by someone else before it is deployed.
- Confirming that a step expression such as */15 9-17 * * 1-5 expands to the hours and days you intend.
- Counting how often a job will run in a month to size a queue or a budget.
What it does not do
- Exactly five fields are required, so the six-field form with a leading seconds column is rejected outright.
- The next-run search steps minute by minute and gives up after a year, so a schedule that fires less often than that returns an empty or short list.
- Fires-per-month is active days multiplied by runs per active day, an upper bound rather than a real calendar count, and fires-per-day is the maximum for the busiest day.
- When both day-of-month and day-of-week are restricted the job runs if either matches, in line with POSIX cron - the opposite of what most people assume - and no specific cron implementation (Vixie, systemd, Quartz) is emulated.