Understanding Cron Expressions

Cron is the scheduler that quietly runs much of the internet — backups, reports, cleanup jobs, CI pipelines. Its syntax is compact and, at a glance, baffling: */15 9-17 * * 1-5 means something precise, but only if you know how to read it. Here is the whole system in one guide.

The five fields

A standard cron expression is five values separated by spaces:

┌ minute (0–59)
│ ┌ hour (0–23)
│ │ ┌ day of month (1–31)
│ │ │ ┌ month (1–12)
│ │ │ │ ┌ day of week (0–6, Sun=0)
* * * * *

Each field answers “which values are allowed here?” The job runs whenever the current time matches every field. * * * * * matches always — so it runs every minute.

The special characters

• * (asterisk) — every value. * * * * * = every minute.
• , (comma) — a list. 0,30 in the minute field = on the hour and half past.
• - (dash) — a range. 1-5 in day-of-week = Monday through Friday.
• / (slash) — steps. */15 in minutes = every 15 minutes (0, 15, 30, 45). 0 */2 * * * = every 2 hours.

You can combine them: 0-30/10 means 0, 10, 20, 30. And 9-17 in the hour field with */15in minutes gives you “every 15 minutes during business hours.”

Reading a real example

*/15 9-17 * * 1-5 breaks down as:

• */15 — every 15 minutes
• 9-17 — during hours 9 through 17 (9am–5pm)
• * — any day of the month
• * — any month
• 1-5 — Monday to Friday

In plain English: every 15 minutes, 9am to 5pm, on weekdays.

The shortcuts

Most cron implementations accept convenient nicknames:

• @hourly = 0 * * * *
• @daily / @midnight = 0 0 * * *
• @weekly = 0 0 * * 0
• @monthly = 0 0 1 * *
• @yearly / @annually = 0 0 1 1 *

The day-of-week gotcha

This one catches almost everyone. When you restrict both day-of-month and day-of-week, standard (Vixie) cron treats them as OR, not AND. So:

0 0 1 * 1 does notmean “midnight on the 1st, if it is a Monday.” It means “midnight on the 1st of the month ORany Monday.” The job fires far more often than you might expect.

The rule: if you need “the 1st only when it's a Monday,” cron can't express that directly — you handle it with a check inside the job. Whenever both day fields are set, double-check the schedule against a real list of next run times.

Two more traps

• Time zones. Most servers run cron in UTC, not your local time. A job set for “9am” may fire in the middle of the night if you forgot the offset. Always confirm which zone your scheduler uses.
• Sunday is both 0 and 7. Cron accepts 0 or 7 for Sunday. They mean the same day; use whichever reads more clearly to you.

Standard 5-field vs extended formats

The classic Unix format has five fields. Some systems add a seconds field at the front (six-field cron, common in Quartz and some libraries) or a year field at the end. If a six-field expression fails in a plain crontab, that extra leading seconds field is usually why. Know which flavor your platform expects.

The safest way to write cron: verify the next runs

Because the syntax is so easy to misread, the reliable workflow is to write the expression, then look at the actual next execution times before trusting it. An off-by-one in the hour field or a misunderstood day rule is obvious the moment you see real dates.

Parse and preview your cron

The free Cron Expression Parser translates any 5-field schedule into plain English and lists the next five run times, so you can confirm it fires exactly when you intend. For working with timestamps, pair it with the Epoch Converter, and when your server runs in UTC, the Time Zone Converter helps you translate the offset.