ZumaTools

Cron Expression Generator

Build a cron schedule with simple selectors, or paste an existing expression to see exactly what it means and when it will run next.

Build an expression

Minute
Hour
Day of month
Month
Day of week
* * * * *

At every minute.

Next 5 run times (your local time)

Computing…

Explain an expression

Paste any standard 5-field cron expression (macros like @daily also work) to see what it means.

Everything runs in your browser — nothing is uploaded. Run times use your local time zone; servers may run cron in UTC.

How it works

  1. Pick a preset or set each of the five fields (minute, hour, day of month, month, day of week) to Every, Every N, or specific values.
  2. Copy the generated expression from the monospace box straight into your crontab, CI pipeline, or scheduler configuration.
  3. To decode an existing schedule, paste it into the explain box and read the plain-English description together with the next five run times.

Frequently asked questions

What do the five fields in a cron expression mean?
From left to right the fields are minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, where 0 is Sunday). An asterisk means every value, */N means every Nth value, 1-5 is a range, and 0,30 is a list. The tool reads and writes all of these forms.
What happens when both day-of-month and day-of-week are restricted?
Standard cron treats this case as OR, not AND: the job fires when either field matches. So 0 0 1 * 1 runs on the 1st of every month and on every Monday, which surprises many people. The explainer calls this out explicitly and the next-run list reflects the OR behavior.
Does this tool support @daily, names like MON, or a seconds field?
It expands the common macros @hourly, @daily, @weekly, @monthly, and @yearly into their five-field equivalents, and it accepts three-letter month and weekday names such as JAN or MON, plus 7 as an alias for Sunday. It does not handle six-field (seconds) syntax or Quartz extensions like L, W, and #, which many cron daemons also reject.
What time zone are the next run times shown in?
All predicted run times are computed and displayed in your browser’s local time zone. A real server often runs cron in UTC or its own configured zone, so a schedule that fires at 09:00 here may fire at a different wall-clock hour on the machine. Always check the server’s time zone before relying on exact hours.
Is my cron expression sent to a server?
No. Parsing, the English explanation, and the next-run calculation all happen locally in JavaScript in your browser, and nothing is transmitted or logged. You can load the page once and keep using the tool offline.

About this tool

This tool works in both directions. The builder lets you assemble a cron expression without memorizing the field order: for each of the five positions you choose between every value, every Nth value, or a specific list such as 0,30 or 9-17, and the finished expression appears live in a monospace box ready to copy. The explainer does the reverse — paste any standard five-field expression and it is translated into a plain-English sentence, followed by the next five times it would actually fire.

Everything runs client-side in your browser. The expression is parsed into sets of allowed minutes, hours, days, months, and weekdays, and the next-run calculator walks forward through the calendar comparing real dates against those sets, so impossible schedules like February 30th are detected honestly instead of producing fake dates. Nothing you type is uploaded anywhere, which also means the tool responds instantly on every keystroke.

Typical uses include writing crontab entries on Linux servers, scheduling GitHub Actions workflows (the schedule trigger uses the same five-field syntax), configuring Kubernetes CronJobs, and double-checking an unfamiliar expression found in a legacy system before touching it. The next-run preview is the fastest way to confirm that */15 9-17 * * 1-5 really means what you think it does — every 15 minutes during working hours on weekdays.

Two practical tips: remember that both day fields being restricted at once combine with OR in standard cron, so prefer restricting only one of them; and note that predicted times use your local clock, while servers frequently run in UTC. When a schedule matters, deploy it, then verify the first real execution in your logs rather than trusting any calculator — including this one — with daylight-saving edge cases.

Related tools