Skip to content
koducathome

Cron Expression Generator & Explainer

Build cron expressions field by field, translate any expression into plain English and preview its next run times.

How to use this tool

Steps for using the Cron Generator.

  1. Pick a preset such as *Weekdays at 9:00*, or type any expression into the Cron expression field — 5 fields, 6 fields with seconds first, or a macro like @daily.
  2. To build a schedule visually, open the Builder tab and set each field (minute, hour, day of month, month, day of week) to *every*, *specific values*, *a range* or *every N*. The expression updates as you change fields.
  3. Read the plain-English Description and the Field breakdown table to confirm each field means what you intended.
  4. Choose a time zone for the Next 10 run times list — UTC, your browser's local zone or any IANA zone such as Europe/Berlin.
  5. If the expression is invalid, the error names the field and the reason (out-of-range value, reversed range, Quartz-only syntax). Fix it and Copy the final expression.

Example

Every 15 minutes during office hours on weekdays

Expression
*/15 9-17 * * 1-5
Description and first runs (UTC, starting 2026-01-01 00:00)
Every 15 minutes, between 09:00 and 17:59, Monday through Friday

2026-01-01 09:00:00 UTC+00:00
2026-01-01 09:15:00 UTC+00:00
2026-01-01 09:30:00 UTC+00:00

Common use cases

  • Writing the schedule of a Kubernetes CronJob and checking when it will fire in the cluster's time zone.
  • Decoding an unfamiliar crontab line on a server before changing it.
  • Choosing a GitHub Actions on.schedule expression and converting the intended local time to UTC.
  • Verifying that a backup or report job does not run during a daylight-saving gap.
  • Translating a Quartz expression from a Java scheduler into standard cron syntax.

How cron expressions work

A standard cron expression has five space-separated fields: minute (0–59), hour (0–23), day of month (1–31), month (1–12 or JAN–DEC) and day of week (0–7 or SUN–SAT, where both 0 and 7 mean Sunday). Each field accepts * (every value), a single value, a list (1,15), a range (9-17) or a step (*/5, 0-30/10). The job runs whenever the current time matches every field. One classic surprise: when both day of month and day of week are restricted, Vixie cron and most implementations run the job when *either* matches — 0 0 13 * 5 fires on every 13th and every Friday. The tool points this out when it applies. For a longer walkthrough see the cron expressions guide.

Before any library is called, the expression is checked by a field validator that reports exactly which field is wrong and why: a value outside the field's range, a range that runs backwards, a zero step, an empty list item, or the wrong number of fields. Valid expressions are described in plain English with the open-source cronstrue library, and the next run times are computed with cron-parser in the time zone you choose, so daylight-saving transitions are reflected. Run times are calculated in your browser after the page loads, using your device clock.

Six-field expressions put seconds first (30 0 9 * * MON = 09:00:30 every Monday). They are used by node-cron, Spring's @Scheduled and similar libraries, but crontab, Kubernetes and GitHub Actions only accept five fields. Macros are shorthand: @hourly = 0 * * * *, @daily and @midnight = 0 0 * * *, @weekly = 0 0 * * 0, @monthly = 0 0 1 * *, @yearly and @annually = 0 0 1 1 *. @reboot is different — it runs once when the cron daemon starts, so it has no upcoming run times to show.

Platforms differ in the details. crontab runs in the server's local time zone unless CRON_TZ is set. Kubernetes CronJobs use the controller's time zone by default (UTC on most managed clusters); since Kubernetes 1.27 you can set spec.timeZone: "Europe/Berlin". GitHub Actions schedule triggers always use UTC, run at most every 5 minutes and can be delayed under load. Quartz (Java) uses 6–7 fields and extra characters — ? (no specific value), L (last), W (nearest weekday) and # (nth weekday). Those are not part of standard cron, so this tool reports them as errors and explains what to use instead.

Limitations

  • Quartz extensions (?, L, W, #) and the optional 7th year field are not supported; they are reported as errors.
  • Next run times come from your device clock; if it is wrong, the list will be too.
  • The builder edits 5-field expressions; seconds and macros can be typed directly but not built field by field.
  • Non-standard extensions such as H (Jenkins hash) or AWS EventBridge syntax are not recognised.

Frequently asked questions

Does cron use my local time zone or UTC?

It depends on where the schedule runs. System crontab uses the server's time zone, Kubernetes uses the controller's zone unless spec.timeZone is set, and GitHub Actions always uses UTC. Pick the matching zone in the run-times list to see what will actually happen.

What does */5 mean?

It is a step: every 5th value of the field starting from its minimum. In the minute field */5 means minutes 0, 5, 10 … 55. 10-30/5 means 10, 15, 20, 25 and 30.

Why does my job run on more days than expected?

If both day of month and day of week are set (neither is *), standard cron runs the job when either one matches. Use only one of the two fields, or check the date inside your script.

Can I schedule a job every 30 seconds?

Not with standard 5-field cron — the smallest unit is one minute. Libraries that accept 6 fields support */30 * * * * *; for crontab, a common workaround is two entries, one of which sleeps 30 seconds before running.

Is 7 or 0 Sunday?

Both. Standard cron accepts 0 and 7 for Sunday in the day-of-week field, and SUN works too. Ranges like 5-7 (Friday to Sunday) are valid.