How to Write a Cron Expression (With Examples)

Open almost any server's crontab and you'll find a line like 0 9 * * 1-5 sitting above a command, with no explanation attached. It looks like noise, but it is a complete, precise sentence: "run this at minute 0 of hour 9, on any day of the month, in any month, on weekdays." Once you know the grammar, that sentence reads as fast as English.

This guide covers that grammar properly: what each of the five fields means, the handful of symbols that combine them, a repeatable method for building any schedule from a plain description, and the single gotcha — mixing day-of-month and day-of-week — that catches almost every developer at least once. If you just want a working expression right now, the cron expression generator builds one for you; if you want to actually understand the syntax, read on.

A cron expression is a compact schedule, not a record of a moment in time. It tells a scheduler when to run something, repeatedly, forever — "every weekday at 9 AM," "every 15 minutes," "the first of every month." That's a different job from a Unix timestamp, which records one specific instant that already happened, counted in seconds since the Unix epoch. A cron expression never points at a single moment; it describes a pattern that a scheduler checks against the clock, minute by minute, forever.

The name comes from cron, the time-based job scheduler built into Unix and Linux systems since the 1970s, and "cron job" now refers to any recurring task scheduled this way — whether it actually runs through the Unix cron daemon or through a cloud scheduler that borrowed its syntax, like AWS EventBridge, Google Cloud Scheduler, or a CI/CD pipeline's scheduled trigger.

A standard cron expression is five fields, separated by single spaces, always in this order:

Every field is filled in — none can be left blank — and a field that isn't restricted is written as *. So 30 14 * * * means "at minute 30 of hour 14 (2:30 PM), every day of the month, every month, every day of the week," which is just a wordy way of saying "every day at 2:30 PM."

Most implementations also accept three-letter names in the month field (jan–dec) and day-of-week field (sun–sat) as an alternative to numbers, though sticking with numbers is safer across different systems since not every scheduler supports the names identically.

Within each field, four symbols cover almost every schedule you'll ever need to write:

• * — asterisk. Means "every value." * in the hour field matches all 24 hours.
• , — comma. A list of specific values. 1,15 in the day-of-month field means "the 1st and the 15th."
• - — hyphen. An inclusive range. 9-17 in the hour field means "9 AM through 5 PM, every hour in between."
• / — slash. A step value, usually paired with * or a range. */15 in the minute field means "every 15th minute, starting from 0" — so minute 0, 15, 30, and 45.

These combine freely. 0,30 9-17 * * 1-5 means "at the top and bottom of every hour, from 9 AM through 5 PM, Monday through Friday" — a reminder every half hour during the business week.

Rather than trying to write the whole expression at once, fill the five fields left to right, starting from the smallest unit and working outward. Here's the method applied to a real request:

Read it back the same way to check your work: minute 0, hour 9, any day of the month, any month, Monday through Friday. That sentence should match the request you started with, word for word — if it doesn't, one of the five fields is wrong.

Pick a value for each field below and watch the expression assemble itself. This covers the schedules most people need; for a wider range of presets and validation, use the full tool.

Most schedules people actually need fall into a short list. Here are the ones worth having memorized or bookmarked.

Every other field in cron combines with an implicit AND — hour and minute and month all have to match. Day of month and day of week are the one exception, and it catches nearly everyone at least once.

When both fields are restricted away from *, cron runs the job if either one matches — an OR, not an AND. Write 0 0 15 * 1 intending "the 15th, if it's a Monday," and cron will actually run the job on every 15th and every Monday, because either condition alone is enough.

Many cron implementations, including the versions shipped with most Linux distributions, accept shorthand strings in place of the five fields for the most common schedules:

• @yearly or @annually — once a year, at midnight on January 1st.
• @monthly — once a month, at midnight on the 1st.
• @weekly — once a week, at midnight on Sunday.
• @daily or @midnight — once a day, at midnight.
• @hourly — once an hour, at minute 0.
• @reboot — once, whenever the system starts up.

A cron expression has no timezone of its own — it's just numbers. The timezone it actually runs in depends entirely on where it's running. A traditional crontab on a Linux server runs in that server's local system timezone, unless a CRON_TZ variable is set at the top of the crontab to override it. Cloud schedulers vary by provider, and several default to UTC rather than any local time.

The practical rule: never assume. Before deploying a time-sensitive schedule, confirm the exact timezone your specific cron implementation or scheduler uses, especially if the server and the team relying on the schedule are in different regions.

• Assuming day-of-month and day-of-week combine with AND. As covered above, restricting both fields together produces an OR.
• Using */2 in the day-of-month field expecting "every other day." Because months have different lengths, this resets at the start of each month and doesn't reliably alternate.
• Forgetting that minutes only run 0–59 and hours only run 0–23 — there's no minute 60 or hour 24 in a standard expression.
• Deploying a schedule without checking the scheduler's timezone, then wondering why a "9 AM" job runs at a different local hour than expected.
• Copying a five-field expression into a scheduler that expects six fields with seconds, shifting every value one position to the left.