Quick answer
The cron expression */15 9-17 * * 1-5 runs every 15 minutes from 9:00 to 17:45, Monday to Friday: 4 times an hour for 9 hours, so 36 runs each weekday. Standard cron has five fields — minute, hour, day of month, month, day of week — as defined for crontab in the POSIX standard.
About the Cron Expression Generator & Explainer
A cron expression is one line of five fields — minute, hour, day of month, month and day of week — that tells a scheduler when to run a job. It is compact and easy to get subtly wrong: a value in the wrong field, a weekday numbered from the other end of the week, or a server on UTC while you think in Eastern time.
In Explain mode, paste an expression from a crontab, a Kubernetes CronJob or a CI pipeline to get a plain-English description, every field expanded into the exact values it matches, and the next run times in your scheduler's time zone. In Build mode, pick a pattern and the page writes the expression, shows how each choice became a field and explains the result back. Everything runs in your browser.
How to use it
In Explain mode, type or paste an expression such as */15 9-17 * * 1-5. Five fields are standard; six are read as seconds first, and nicknames such as @daily are expanded. Results update as you type, and an invalid expression is highlighted with the reason.
Switch to Build when you know the schedule but not the syntax. Choose how often the job runs — every N minutes, hourly, daily, on chosen weekdays or monthly — and fill in the fields that appear. Hours use the 24-hour clock, so 6:30 PM is hour 18, minute 30. Show the math lists how each choice became a field.
Under Next run times, enter the time zone your scheduler runs in and how many runs to list, up to 20. When the expression suits them, the results include a crontab line and a Kubernetes spec with copy buttons, and Copy link saves your inputs in the address for a teammate.
Use cases
- Reviewing a pull request. Confirm that a new CronJob's "weekday mornings" really means Monday to Friday at 9:00 in the cluster's zone, not 9:00 UTC.
- Debugging a job that ran at the wrong time. Compare runs in local time and UTC to spot an offset or a daylight saving shift.
- Catching the day-of-month trap. See at once when a schedule that sets both a date and a weekday runs on far more days than intended.
- Moving a job between schedulers. Check a Quartz or AWS-style expression after removing the fields standard cron lacks, and see where weekday numbering differs.
How a cron expression is read
Left to right, the fields are minute, hour, day of month, month and day of week. A job runs at every minute where all five match, with one exception for the two day fields, covered below. Here is 0,30 9-17 * */3 1-5, which uses each kind of value standard cron allows:
| Field | Allowed values | Example | Matches |
|---|---|---|---|
| Minute | 0–59 | 0,30 | 0, 30 |
| Hour | 0–23 | 9-17 | 9, 10, 11, 12, 13, 14, 15, 16, 17 |
| Day of month | 1–31 | * | every day of the month |
| Month | 1–12 or JAN–DEC | */3 | Jan, Apr, Jul, Oct |
| Day of week | 0–7 or SUN–SAT (0 and 7 = Sunday) | 1-5 | Mon, Tue, Wed, Thu, Fri |
Together it reads: At 0 and 30 minutes past the hour, between 09:00 AM and 05:59 PM, Monday through Friday, every 3 months. Four characters do the work:
*matches every allowed value.,separates a list:0,30is on the hour and at half past.-is an inclusive range:9-17includes the 5 PM hour, so0,30 9-17last runs at 5:30 PM./adds a step:*/15is every 15th value from the lowest, and10-50/20in the minute field is 10, 30, 50.
Months and weekdays also accept three-letter names such as JAN or MON. Day of week runs from 0 to 7, and both 0 and 7 mean Sunday, so 1-5 is Monday through Friday; Kubernetes is stricter and accepts only 0 to 6. Some older crontabs accept a name only on its own, not in a range or list, so numbers are the most portable.
Steps start over at the end of each cycle. */7 in the minute field matches 0, 7, 14, 21, 28, 35, 42, 49, 56; the next match is :00 of the following hour, only 4 minutes after :56. Likewise 0 */5 * * * runs at 0, 5, 10, 15, 20 o'clock and again at midnight, 4 hours later. The results flag these uneven gaps. For minutes, only 1, 2, 3, 4, 5, 6, 10, 12, 15, 20 and 30 divide the hour evenly.
The day-of-month OR day-of-week rule
When both day fields are restricted — neither is * — standard cron runs the job on days that match either field. 0 0 13 * 5 looks like "midnight on Friday the 13th", but from Thu, Oct 8, 2026, 12:00 PM UTC its next runs are:
- Fri, Oct 9, 2026, 12:00 AM UTC
- Tue, Oct 13, 2026, 12:00 AM UTC
- Fri, Oct 16, 2026, 12:00 AM UTC
- Fri, Oct 23, 2026, 12:00 AM UTC
- Fri, Oct 30, 2026, 12:00 AM UTC
That is every Friday plus every 13th. Standard cron cannot say "only when both match"; schedule on one field and test the other inside the command instead — run every Friday and exit unless the date is the 13th. Quartz and AWS avoid the problem by requiring ? in one of the two fields.
One edge case: in Vixie cron and its descendants, a day field that merely starts with an asterisk, such as */2, counts as unrestricted, so there 0 0 */2 * 1 means odd-numbered days that are also Mondays. This tool treats anything other than a bare * as restricted, so confirm such schedules on the machine that runs them.
Nicknames
Most cron daemons accept these shortcuts in place of the five fields, and the tool expands them:
| Nickname | Same as | Runs |
|---|---|---|
@yearly | 0 0 1 1 * | At 12:00 AM, on day 1 of the month, only in January |
@annually | 0 0 1 1 * | At 12:00 AM, on day 1 of the month, only in January |
@monthly | 0 0 1 * * | At 12:00 AM, on day 1 of the month |
@weekly | 0 0 * * 0 | At 12:00 AM, only on Sunday |
@daily | 0 0 * * * | At 12:00 AM |
@midnight | 0 0 * * * | At 12:00 AM |
@hourly | 0 * * * * | Every hour |
@reboot runs once when the cron daemon starts. It is not a schedule, so the tool rejects it. So does @every 5m, from Go's robfig/cron: it repeats at a fixed interval counted from when the scheduler started, not at set clock times, so it has no fields to expand.
Worked examples
Every 15 minutes in business hours. */15 9-17 * * 1-5 in America/New_York reads: Every 15 minutes, between 09:00 AM and 05:59 PM, Monday through Friday. From Thu, Oct 8, 2026, 8:00 AM EDT, the first runs are Thu, Oct 8, 2026, 9:00 AM EDT; Thu, Oct 8, 2026, 9:15 AM EDT; Thu, Oct 8, 2026, 9:30 AM EDT. The last run each weekday is 5:45 PM, because the hour range includes 17 and the minute field allows :45.
Built: Monday, Wednesday and Friday at 6:30 PM. Choose On days of the week, tick the three days and enter hour 18, minute 30. The builder writes 30 18 * * 1,3,5 — minute 30, hour 18, weekdays 1,3,5. In America/Chicago the next runs are Fri, Oct 9, 2026, 6:30 PM CDT; Mon, Oct 12, 2026, 6:30 PM CDT; Wed, Oct 14, 2026, 6:30 PM CDT.
Once a month on the 31st. 0 0 31 * * next runs Sat, Oct 31, 2026, 12:00 AM UTC; Thu, Dec 31, 2026, 12:00 AM UTC; Sun, Jan 31, 2027, 12:00 AM UTC; Wed, Mar 31, 2027, 12:00 AM UTC. November and February are missing because they have no 31st; cron skips such months rather than moving the run to the last day.
Quartz, Kubernetes and AWS EventBridge
Several schedulers say "cron" but mean slightly different things. This tool reads standard five-field cron and the six-field variant with seconds first.
| Feature | Standard cron | Quartz | Kubernetes CronJob | AWS EventBridge |
|---|---|---|---|---|
| Fields | 5 | 6 or 7 | 5 | 6 |
| Seconds | No | First field | No | No |
| Year | No | Optional, last | No | Required, last |
| Sunday is | 0 or 7 | 1 | 0 (7 is rejected) | 1 |
| Both day fields set | Either matches | Not allowed; one must be ? | Either matches | Not allowed; one must be ? |
| Time zone | The machine's clock | Set on the trigger | timeZone field | UTC for rules; Scheduler can set one |
Quartz puts seconds first and allows a trailing year. It numbers weekdays 1 to 7 from Sunday, so a Quartz 2 is Monday while a cron 2 is Tuesday; names avoid the mix-up. One day field must be ? ("no specific value"). A six-field expression such as 0 30 9 ? * MON-FRI works here as is and reads "At 09:30 AM, Monday through Friday"; drop the year from a seven-field one.
Kubernetes CronJob takes standard five-field cron and the nicknames in spec.schedule, with two restrictions: day of week runs 0 to 6 only, so 7 and ranges such as 1-7 fail validation, and the extensions L, W and # are not supported. Set spec.timeZone to an IANA name (a stable field since Kubernetes 1.27); otherwise the schedule follows the kube-controller-manager's zone. CRON_TZ= or TZ= inside the schedule is not supported, and current versions reject it.
AWS EventBridge writes cron(minutes hours day-of-month month day-of-week year): no seconds, a year at the end, one day field set to ?, and weekdays 1 to 7 from Sunday. Scheduled rules run in UTC; EventBridge Scheduler can attach a time zone. To check one here, drop the year and change ? to *: 0 18 ? * MON-FRI * becomes 0 18 * * MON-FRI. Paste it as is, with or without the cron( ) wrapper, and the tool suggests that conversion instead of misreading the first field as seconds.
AWS and Quartz also write steps with a starting number, such as 0/15 for "every 15 minutes from :00". Standard cron spells that */15, or a range with a step such as 5-59/15 when the start is not the lowest value, and some implementations reject the short form. The suggested conversion rewrites it, so 0/15 * ? * MON-FRI * becomes */15 * * * MON-FRI. In a five- or six-field expression the tool makes the same change on its own: 0/15 * * * * is checked as */15 * * * *, with a note saying so.
Time zones and daylight saving time
Classic cron has no time zone field: it follows the clock of the machine it runs on, usually UTC for servers and containers. Some daemons accept a CRON_TZ= line in the crontab, and Go's robfig/cron reads a prefix on the schedule itself, as in CRON_TZ=America/New_York 0 9 * * *; paste that form and the tool lists the runs in the prefixed zone. Otherwise, set the time zone field above to whatever your scheduler really uses; the time zone converter turns "9 AM in Chicago" into UTC hours.
Daylight saving time skips or repeats an hour. For 30 2 * * * in America/New_York, 2:30 AM does not exist the morning clocks jump forward in March, so the tool lists Sun, Mar 14, 2027, 3:30 AM EDT, then Mon, Mar 15, 2027, 2:30 AM EDT. When clocks fall back in November, the repeated hour is listed once: from just before 1 AM, */30 * * * * lists 1:00 AM EDT, 1:30 AM EDT, 2:00 AM EST and 2:30 AM EST.
Vixie cron and cronie treat the two kinds of job differently. A job at a fixed time that falls in the skipped hour runs soon after the jump, and one in the repeated hour is not run a second time. A job with * in the minute or hour field simply follows the new clock, so it skips the spring-forward gap and runs again during the repeated fall-back hour. Other schedulers have their own rules, so jobs that must run exactly once a day are safest outside 1–3 AM local time, or on UTC.
Limits of this tool
- It reads five-field cron and six fields with seconds first. Seven-field Quartz and AWS expressions need converting; the tool says how.
- It also accepts the extensions
L,Wand#, which plain crontab and Kubernetes reject, so no ready-to-paste lines are offered for them. - Run times come from the calendar alone. A job still running, a host that was down or a Kubernetes
concurrencyPolicycan delay or skip real runs. - The plain-English sentence is generated; for unusual combinations, trust the field table.
Sources
- The Open Group — POSIX crontab utility — checked
Frequently asked questions
What does */5 mean in a cron expression?
Every fifth value of the field, counting from its lowest value. In the minute field, */5 matches 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, so */5 * * * * runs every five minutes. A range can take a step too: 0-30/10 is 0, 10, 20, 30.
What is the cron expression for every weekday at 9 AM?
0 9 * * 1-5: minute 0, hour 9, any day of the month, any month, days 1 through 5 (Monday to Friday). On a UTC server that is 9 AM UTC — 4 or 5 AM in New York, depending on daylight saving time — so check the scheduler's time zone.
Why does my cron job run on days I didn't expect?
Usually the OR rule: with both day of month and day of week set, the job runs on days matching either, so 0 0 13 * 5 fires every Friday and every 13th. Other causes are weekday numbers copied from Quartz or AWS, where 2 is Monday, and a server time zone that pushes evening runs past midnight.
How do I run a cron job on the last day of the month?
Standard crontab has no symbol for it. Run on days 28 to 31 and exit unless tomorrow is the 1st: 0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && /path/to/command with GNU date. The % is escaped because crontab turns a bare % into a newline. Quartz, AWS and some libraries accept L in the day-of-month field.
Can cron run a job every 90 minutes?
Not with one line, because minute steps restart every hour. Two lines do it: 0 0-21/3 * * * runs on the hour at 0, 3, 6, 9, 12, 15, 18, 21, and 30 1-22/3 * * * at half past 1, 4, 7, 10, 13, 16, 19, 22 — sixteen runs a day, 90 minutes apart.
Are 0 and 7 both Sunday in cron?
In standard cron (Vixie cron, cronie and their descendants), yes: the day-of-week field accepts 0 to 7 and both ends mean Sunday, so 1-7 matches every day of the week (all 7). Kubernetes CronJob accepts only 0 to 6 and rejects 7, so write Sunday as 0 or SUN there; this page leaves out the Kubernetes snippet when the field uses 7 and shows the replacement. Quartz and AWS EventBridge count 1 to 7 with 1 as Sunday.
Is my cron expression sent anywhere?
No. The description, field table and run times are computed in your browser, and typing makes no network request; your inputs are only copied into the address bar so the link can be shared. Scripts and AI agents can call the same explainer as a JSON API or MCP tool — see the developer page.
Disclaimer. Run times follow standard cron rules in the time zone you choose; real schedulers differ in details such as daylight saving handling, the day-field OR rule and extensions like L and #, so confirm critical schedules on the system that will run them.
Last updated . Found a mistake? Tell us — corrections ship the same week.