Skip to content
ToolBoxGenie

Cron Expression Generator

Developer Tools · Added 18 August 2026

Build a cron schedule field by field, or paste an existing expression and have it read back to you in plain English with its next run times. The tool also flags the trap that catches almost everyone: when both the day-of-month and day-of-week fields are set, cron runs when either matches, not both.

Mode
The five fields

0–59

0–23

1–31

1–12 or JAN–DEC

0–6 or SUN–SAT

Each field takes * for every value, a number, a list (1,15), a range (1-5) or a step (*/15).

Schedule

Cron expression

*/15 * * * *

Every 15 minutes every day.

Runs per day
96
Roughly
every 15 min
Time zone
local

Your browser's — the server's may differ

Shorthand equivalents

No standard shorthand matches this schedule. The macros are @yearly, @annually, @monthly, @weekly, @daily, @midnight, @hourly.

Run times are calculated in your browser's time zone. A cron daemon uses the server's, and containers frequently run in UTC regardless of where they are deployed — check TZ or the scheduler's own time zone setting before trusting a specific clock time.

How to use the cron expression generator

  1. 1Choose Build to fill in the five fields, or Explain to paste an existing expression.
  2. 2Start from a preset if one is close to what you need, then adjust.
  3. 3Read the plain-English description to confirm it means what you intended.
  4. 4Check the next run times — they are computed in your browser's time zone.
  5. 5Copy the expression into your crontab, CI configuration or scheduler.

Examples

Weekdays at 9am

Input
0 9 * * 1-5
Result
At 9:00am on Monday, Tuesday, Wednesday, Thursday and Friday.

Every fifteen minutes

Input
*/15 * * * *
Result
Every 15 minutes — 96 runs a day

The either/or trap

Input
0 0 1 * 1
Result
Runs on the 1st of the month OR every Monday — about 56 times a year, not 12

Almost nobody means this. Leave one of the two day fields as * unless you want the union.

About the cron expression generator

Why cron syntax is worth ten minutes

Cron has scheduled the world's background work since 1975, and the five-field syntax has outlived several generations of tooling built to replace it. Kubernetes CronJobs, GitHub Actions, systemd timers, most CI systems and most managed schedulers all accept it, which means the syntax is worth understanding once rather than looking up every time.

The syntax is also unforgiving in a specific way: a wrong expression is still a valid one. There is no error to catch, just a job that runs at the wrong time or a hundred times more often than intended. Reading the schedule back in English before you commit it is the cheapest possible check.

Steps, ranges and the ones that do not wrap

A step applies to a range: */15 in the minute field means every 15 minutes starting from 0, and 0-30/5 means every 5 minutes in the first half hour only. A step on a bare number is unusual and means 'from here to the end of the range', so 5/10 in the minute field is 5, 15, 25, 35, 45, 55.

Ranges do not wrap around. 22-2 in the hour field is not 10pm to 2am — it is an error, because the start is after the end. The way to express an overnight window is a list of two ranges: 22-23,0-2.

Before you deploy the schedule

Three things worth checking beyond the syntax. First, whether the job is safe to run twice — schedulers retry, clocks change, and a job that assumes exactly-once delivery will eventually be wrong. Second, whether it is safe to overlap: cron starts a new run on schedule regardless of whether the previous one has finished, and a slow job on a tight schedule can pile up until the machine falls over. A lock file is the usual answer.

Third, where the output goes. Classic cron mails stdout to the user and silently discards it if no mailer is configured, which is how a job can fail every night for months without anyone noticing. Redirect the output somewhere you will actually see it, and make failure loud.

Frequently asked questions

What do the five fields mean?
In order: minute (0–59), hour (0–23), day of month (1–31), month (1–12 or JAN–DEC) and day of week (0–6 or SUN–SAT, where both 0 and 7 mean Sunday). Each accepts a star for every value, a single number, a list such as 1,15, a range such as 1-5, or a step such as */15. A job runs when every field matches the current time.
Why does setting both day fields run more often than expected?
Because cron treats them as a union rather than an intersection. If day-of-month and day-of-week are both restricted, the job runs on any day matching either one. The behaviour goes back to the original Vixie cron and every mainstream implementation copies it. To run on, say, the first Monday of the month, you cannot express it in standard cron — you check the date inside the job and exit early.
Which time zone do the next run times use?
Your browser's, and the tool says so on the page. A real cron daemon uses the server's time zone, and containers very often run in UTC regardless of where they are deployed. Before relying on a specific clock time, check the TZ environment variable, the CRON_TZ setting, or your scheduler's own time zone option — this is the single most common reason a job fires at an unexpected hour.
What happens during a daylight saving change?
It depends on the implementation, and none of the answers are pleasant. A job scheduled for 2:30am may be skipped on the day the clock jumps forward and run twice on the day it goes back. Modern versions of Vixie cron try to compensate for jobs scheduled once a day, but stepped schedules get no such help. If a job must not be skipped or duplicated, schedule it in UTC or avoid the hour either side of the transition.
Does it support seconds, or the L and # characters?
No. This is standard five-field Unix cron. Six-field expressions with a seconds column belong to Quartz, Spring and some cloud schedulers, and the special characters L (last), W (nearest weekday) and # (nth weekday of the month) are Quartz extensions. A six-field expression is detected and reported rather than mis-parsed. AWS EventBridge uses six fields with year rather than seconds, which is different again.
What are @daily and @reboot?
Shorthand macros most implementations accept: @yearly, @monthly, @weekly, @daily (also @midnight) and @hourly. All are recognised here and expanded to their five-field equivalent. @reboot is not a schedule at all — it runs once when cron starts — so it has no expression and no next run time.

Related tools