What do the five fields in a cron expression mean, and in what order?

From left to right: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), and day-of-week (0-6, where 0 and 7 both mean Sunday). They are separated by single spaces and always appear in that order. So 0 9 * * 1-5 means minute 0, hour 9, any day-of-month, any month, Monday through Friday — that is, 09:00 on every weekday.

Why does my job run on extra days when I set both the day-of-month and the day-of-week?

This is the single most common cron surprise. When BOTH the day-of-month field and the day-of-week field are restricted to something other than the wildcard, standard cron combines them with OR, not AND. So 0 0 13 * 5 does not mean "midnight on Friday the 13th" — it means "midnight on the 13th of any month, AND midnight on every Friday." If you truly need the AND behaviour, restrict only one of the two fields and enforce the other condition inside your script, or split the schedule into separate lines. This tool detects the both-restricted case and explains the OR behaviour explicitly so you are never caught by it.

Can a standard cron expression schedule something every few seconds?

No. The classic five-field POSIX cron has no seconds field; its finest resolution is one minute. Second-level scheduling requires a six-field variant where the first field is seconds, used by the Quartz scheduler, some Kubernetes CronJob operators, and various language libraries. Those are not portable to a standard Unix crontab. If you paste a six-field string here it will be flagged, because this tool targets the standard five-field form that the POSIX crontab specification defines.

What is the difference between */10 and a plain 10 in a field?

A step value like */10 in the minute field means "every 10 minutes" — it matches minutes 0, 10, 20, 30, 40, and 50. A plain 10 matches only the single value 10, so the job fires just once per hour at minute 10. Steps can also be scoped to a range: 0-30/10 matches 0, 10, 20, and 30 only. Mixing these up is a frequent cause of jobs running far more or far less often than intended, which the next-run preview makes immediately obvious.

Why does AI chat often get cron edge cases wrong, and how does a next-run preview help?

A general-purpose language model generates cron expressions from patterns in its training data, so it is confident and usually right on common schedules but unreliable on the edge cases — the day-of-month versus day-of-week OR rule, step-and-range interactions, and the zero-versus-seven Sunday ambiguity. It cannot actually execute the schedule to check itself, so a subtly wrong expression is returned with the same certainty as a correct one. This tool is deterministic: it parses the expression the same way a scheduler evaluates it and computes real timestamps for the next five runs. You are checking behaviour, not a plausible-sounding explanation, which is exactly where the AI answer tends to fall down.

Does this tool send my cron expression anywhere or store it?

No. Everything — validation, the plain-English explanation, and the next-run computation — happens entirely in your browser with hand-rolled JavaScript. Nothing is sent to a server, nothing is logged, and no cron expression you type is stored or associated with your visit. You can use it offline once the page has loaded.

Which cron syntax does this tool support?

It supports the standard five-field POSIX crontab syntax with the four common field operators: the wildcard (*), single values, comma-separated lists (1,15,30), inclusive ranges (1-5), and steps (*/10 or 0-30/10). It does not currently interpret named shorthands such as @daily or @reboot, three-letter month and weekday names, or non-standard extensions like the L (last) and W (weekday) qualifiers found in Quartz. Stick to numeric five-field expressions for accurate results.

Text

Cron Expression Builder & Explainer

Build a cron expression from plain selects, or paste one and get a plain-English explanation plus the next five run times computed live in your browser. Free, no signup, no ads.

By the Samastam teamLast updated 2026-07-25

Cron expression

MinuteHourDay of monthMonthDay of week

Try:

Type a five-field cron expression above, or build one below. The plain-English reading and the next five run times appear here automatically.

Build field by field

Minute (0–59)

Hour (0–23)

Day of month (1–31)

Month (1–12)

Day of week (0–6)

Every change writes straight into the expression box above, so the reading and next-run preview stay in sync.

A cron expression is the five-field schedule string — minute, hour, day-of-month, month, day-of-week — that Unix-like systems use to decide when a recurring job should fire. Paste one below to read it back in plain English and see exactly when it runs next, or build one field by field and copy the result.

Key takeaways

A standard cron expression has five space-separated fields in a fixed order: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), and day-of-week (0-6, where 0 and 7 both mean Sunday).
Each field accepts a wildcard (*), a single value, a comma list (1,15,30), an inclusive range (1-5), or a step (*/10), and these can be combined inside one field (0-30/10).
When BOTH day-of-month and day-of-week are restricted, standard cron treats them as OR, not AND — the job runs when EITHER matches, which surprises almost everyone the first time.
The five-field form has no seconds field. Second-level scheduling belongs to six-field variants used by Quartz, some Kubernetes operators, and certain language libraries — not to POSIX crontab.
A deterministic next-run preview is the fastest way to catch a mistake, because a schedule that looks right in English can still fire at the wrong minute once the OR rule and step boundaries are applied.

What this is and why it matters

Cron is the time-based job scheduler that has shipped with Unix and Linux systems for decades, and the cron expression is the small piece of syntax that tells it when to act. Every automated backup, log rotation, certificate renewal, cache purge, database dump, and nightly report on a typical server is driven by one of these five-field strings sitting in a crontab. The syntax is compact by design, which makes it powerful but also easy to misread. A single character difference between 0 0 * * 0 and 0 0 * * * is the difference between a weekly job and a daily one, and nothing in the raw string announces that distinction to a tired engineer at 2 AM.

The reason a builder and explainer matters is that cron fails silently. There is no compiler error for a schedule that is syntactically valid but semantically wrong. The job simply runs at a time you did not intend, or does not run when you expected, and you often discover the gap only when a backup is missing or a report never arrived. Reading an expression back in unambiguous English before you commit it to a crontab closes that gap. Seeing the concrete next five timestamps closes it even more firmly, because a date is far harder to misinterpret than a pattern.

The syntax also carries genuine footguns that trip up experienced people. The day-of-month and day-of-week fields combine with OR rather than AND when both are constrained, step values interact with ranges in non-obvious ways, and the zero-versus-seven ambiguity for Sunday is a perennial source of off-by-one scheduling. A tool that parses the expression deterministically, the same way the scheduler will, removes the guesswork and lets you verify intent against behaviour rather than against a mental model that may be wrong.

How to use this tool

Decide which direction you need. If you already have a cron expression from a config file, a Dockerfile, a CI pipeline, or a colleague and you want to understand it, use the explain direction: type or paste the five fields into the expression box at the top. If you are starting from scratch and know when you want the job to run, use the build direction: adjust the per-field selects and inputs below and watch the expression assemble itself live into the same box.

When explaining, type the five fields separated by single spaces in the standard order — minute, hour, day-of-month, month, day-of-week. The tool validates each field independently as you type. Any field that is out of range or malformed is flagged with an inline red message naming the exact field, so a bad hour value does not silently poison the whole read. Valid expressions render immediately as a plain-English sentence describing the schedule.

Read the next-run preview. Below the explanation the tool computes the next five times the schedule will fire, starting from the current moment, and lists them as concrete timestamps. This is the strongest verification step: the sentence tells you the intent, the timestamps confirm the behaviour. If the two disagree with what you meant, adjust before you deploy.

When building, use the field controls to pick a wildcard, a single value, a list, a range, or a step for each of the five positions. The expression box updates on every change so the two views never drift apart. Once it reads the way you want, use the copy button to lift the expression straight into your crontab, your workflow YAML, or your scheduler config without retyping.

Examples and use cases

Scheduling a nightly database backup

A backend engineer wants a full Postgres dump to run every night at 2:30 AM, when traffic is lowest. They build the expression 30 2 * * * and the explainer reads it back as "At 02:30, every day." The next-run preview lists the coming five nights at 02:30, confirming there is no accidental day-of-week restriction. Satisfied, they copy the expression into the crontab entry that pipes pg_dump to object storage. The plain-English read caught what a raw string would have hidden: an earlier draft of 30 2 * * 1 would have limited the dump to Mondays only, leaving six nights unprotected.

Purging a CDN cache every fifteen minutes during business hours

A platform team needs a cache-purge job to run every fifteen minutes, but only between 9 AM and 6 PM on weekdays. Using the step and range controls they assemble */15 9-17 * * 1-5, and the explainer confirms "Every 15 minutes, between 09:00 and 17:59, Monday through Friday." The next-run list shows the purges clustering inside the working day and stopping overnight, exactly as intended. Building this by hand risks writing 15 instead of */15, which would fire only once per hour at minute 15 — a quarter of the intended frequency, and a bug that would only surface as stale content complaints.

Sending a weekly report on the first Monday-through-Friday of each month

An analyst wants a summary email at 8 AM on the first day of every month, and separately every weekday. They paste 0 8 1 * 1-5 expecting "8 AM on the 1st, but only if it is a weekday." The explainer instead warns that because both day-of-month and day-of-week are set, cron uses OR: the job runs at 8 AM on the 1st of the month AND on every Monday through Friday. Seeing the next-run timestamps land on far more days than expected, the analyst splits it into two separate crontab lines — the classic fix for the OR gotcha.

Frequently asked questions

What do the five fields in a cron expression mean, and in what order?: From left to right: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), and day-of-week (0-6, where 0 and 7 both mean Sunday). They are separated by single spaces and always appear in that order. So 0 9 * * 1-5 means minute 0, hour 9, any day-of-month, any month, Monday through Friday — that is, 09:00 on every weekday.
Why does my job run on extra days when I set both the day-of-month and the day-of-week?: This is the single most common cron surprise. When BOTH the day-of-month field and the day-of-week field are restricted to something other than the wildcard, standard cron combines them with OR, not AND. So 0 0 13 * 5 does not mean "midnight on Friday the 13th" — it means "midnight on the 13th of any month, AND midnight on every Friday." If you truly need the AND behaviour, restrict only one of the two fields and enforce the other condition inside your script, or split the schedule into separate lines. This tool detects the both-restricted case and explains the OR behaviour explicitly so you are never caught by it.
Can a standard cron expression schedule something every few seconds?: No. The classic five-field POSIX cron has no seconds field; its finest resolution is one minute. Second-level scheduling requires a six-field variant where the first field is seconds, used by the Quartz scheduler, some Kubernetes CronJob operators, and various language libraries. Those are not portable to a standard Unix crontab. If you paste a six-field string here it will be flagged, because this tool targets the standard five-field form that the POSIX crontab specification defines.
What is the difference between */10 and a plain 10 in a field?: A step value like */10 in the minute field means "every 10 minutes" — it matches minutes 0, 10, 20, 30, 40, and 50. A plain 10 matches only the single value 10, so the job fires just once per hour at minute 10. Steps can also be scoped to a range: 0-30/10 matches 0, 10, 20, and 30 only. Mixing these up is a frequent cause of jobs running far more or far less often than intended, which the next-run preview makes immediately obvious.
Why does AI chat often get cron edge cases wrong, and how does a next-run preview help?: A general-purpose language model generates cron expressions from patterns in its training data, so it is confident and usually right on common schedules but unreliable on the edge cases — the day-of-month versus day-of-week OR rule, step-and-range interactions, and the zero-versus-seven Sunday ambiguity. It cannot actually execute the schedule to check itself, so a subtly wrong expression is returned with the same certainty as a correct one. This tool is deterministic: it parses the expression the same way a scheduler evaluates it and computes real timestamps for the next five runs. You are checking behaviour, not a plausible-sounding explanation, which is exactly where the AI answer tends to fall down.
Does this tool send my cron expression anywhere or store it?: No. Everything — validation, the plain-English explanation, and the next-run computation — happens entirely in your browser with hand-rolled JavaScript. Nothing is sent to a server, nothing is logged, and no cron expression you type is stored or associated with your visit. You can use it offline once the page has loaded.
Which cron syntax does this tool support?: It supports the standard five-field POSIX crontab syntax with the four common field operators: the wildcard (*), single values, comma-separated lists (1,15,30), inclusive ranges (1-5), and steps (*/10 or 0-30/10). It does not currently interpret named shorthands such as @daily or @reboot, three-letter month and weekday names, or non-standard extensions like the L (last) and W (weekday) qualifiers found in Quartz. Stick to numeric five-field expressions for accurate results.

Sources

Related tools

← All text tools Browse all tools →