Cron expression examples, explained

The five fields

A standard Unix cron expression is five fields separated by spaces. You read them left to right, and each field answers one question about when the job should run. The fields are, in order: minute, hour, day of month, month, and day of week.

So 30 9 * * 1 reads as “at minute 30 of hour 9, on any day of the month, in any month, but only on day-of-week 1 (Monday)” — in other words, 09:30 every Monday. The two asterisks for day-of-month and month say “do not constrain those”, and the 1 in the last field pins it to Mondays. Almost every schedule you will write follows this shape: a fixed minute and hour, and asterisks or a single weekday in the date fields.

Operators: * , - /

Each field accepts more than a single number. Four operators do almost all the work, and once they click, most cron expressions become readable at a glance.

• Asterisk (*) means “every value”. In the hour field it is every hour; in day-of-week it is every day. All five asterisks, * * * * *, is “every minute”.
• Comma (,) is a list. 0 9,17 * * * runs at 09:00 and 17:00 — twice a day, at exactly those two hours.
• Hyphen (-) is a range. 0 9-17 * * 1-5 runs on the hour from 09:00 through 17:00, Monday to Friday — a classic business-hours schedule.
• Slash (/) is a step. */5 in the minute field is “every fifth minute”; 0 */2 * * * is “every two hours on the hour”. The step counts from the start of the field’s range, so */15 fires at :00, :15, :30 and :45.

Combine them freely. 0 8-18/2 * * 1-5 means “every two hours from 08:00 to 18:00, Monday to Friday”. The order of fields never changes, so once you can read the operators you can read any expression.

The examples you actually need

In practice a handful of schedules cover the overwhelming majority of jobs. Here are the ones worth memorising, each as a copy-ready expression with the plain-English meaning. Click any label for the live next-run preview and the per-dialect variants.

Every N minutes or hours

The step operator is the one people get wrong most often, so it is worth being precise. */5 * * * * does not mean “five minutes after the job last finished”; cron has no memory of the previous run. It means “at every minute whose value is a multiple of five”, anchored to the top of the hour. So the job fires at :00, :05, :10 and so on, regardless of how long the previous run took. If a run takes seven minutes, the next scheduled fire at the six-minute mark has already passed and the one after it may start while the first is still running.

That anchoring is also why */7 * * * * behaves oddly: 60 is not divisible by 7, so the job fires at :00, :07, :14 … :56, and then the next fire is :00 of the following hour — only four minutes after :56, not seven. If you genuinely need an even seven-minute cadence, cron is the wrong tool; use a job runner that schedules relative to completion. For the clean divisors — 2, 3, 5, 6, 10, 12, 15, 20, 30 minutes, and 2, 3, 4, 6, 12 hours — the step operator is exactly right, and each has its own example page with the next-run list:

• Every 5 minutes — */5 * * * *
• Every 15 minutes — */15 * * * *
• Every 30 minutes — */30 * * * *
• Every 2 hours — 0 */2 * * *
• Every 6 hours — 0 */6 * * *

Browse every example

The full set of 48 example schedules, grouped by cadence. Each page is a live, interactive reference: the human translation, the next ten run times computed in your browser, copy buttons for seven scheduler dialects, and the gotcha that bites people on that particular pattern.

Dialects differ — do not assume five fields

“Cron” is not one syntax. The classic five-field crontab is the baseline, but many of the places you will paste an expression in 2026 use a variant. The differences are small but they fail loudly when you get them wrong.

• GitHub Actions and Kubernetes CronJobs use the standard five fields, and both run in UTC by default. Kubernetes lets you set a timeZone field; GitHub Actions does not, so you must do the UTC arithmetic yourself.
• Quartz (Java) and Spring use six or seven fields, adding a leading seconds field and, for Quartz, a trailing year. Quartz also requires a ? in whichever of day-of-month or day-of-week you are not constraining, because it refuses to let both be specified at once.
• AWS EventBridge uses six fields with a year, and shares Quartz’s ? rule. Vercel Cron uses the standard five fields and runs in UTC.

Every example page on this site shows the correct expression for all seven dialects side by side, derived mechanically from the canonical Unix form, so you can copy the right one for your platform without hand-translating. If you maintain jobs across several systems, the GitHub Actions cron picker, Kubernetes CronJob validator, and EventBridge converter each validate against that platform’s exact rules.

The gotchas

Three mistakes account for most cron incidents. First, the day-of-month and day-of-week trap: if you set both fields, classic cron treats them as OR, not AND. 0 0 13 * 5 does not mean “Friday the 13th”; it means “the 13th of the month, or any Friday”. To pin a specific weekday you must leave day-of-month as an asterisk.

Second, the time-zone trap. A schedule that reads 0 9 * * * means 9am, but 9am where? On a Linux box it is the server’s local zone; on GitHub Actions and Vercel it is UTC. If your server observes daylight saving, a fixed local-time cron will shift by an hour twice a year relative to UTC, which can matter for jobs that coordinate with external systems. When the timing must be exact across a DST change, schedule in UTC or have the job check the wall-clock time itself. The cron timezone translator converts a local schedule to the UTC expression a managed runner needs.

Third, overlap. Cron starts a job on schedule whether or not the previous run has finished. A */5 job that occasionally takes six minutes will run two copies at once. If overlap is unsafe, add a lock in the job itself or use a runner that suppresses concurrent runs — cron will not do it for you.

Tools Zeitful ships for cron

• The cron expression builder — build or paste an expression and watch the next ten run times update live.
• The cron cheat sheet — the most common schedules on one page, each with its next run time.
• The cron timezone translator — convert a local-time schedule to the UTC expression a managed runner needs.
• The per-pattern cron example pages — one indexable, interactive page per schedule in the table above.

For the authoritative syntax, the crontab(5) man page is the reference for classic Unix cron, and each scheduler’s own docs cover its dialect’s extra fields.

FAQ