Cron has been the standard way to schedule recurring jobs on Unix-like systems since the 1970s, and it's still what runs behind most deploy pipelines, backup scripts, and CI workflows today. The syntax is compact enough to be genuinely confusing the first few times you see it, but the logic underneath is simple once it clicks.
The five fields
A standard cron expression has five fields, in this order:
minute hour day-of-month month day-of-week
Each field accepts a number, a range, a list, or * (meaning "every value"). So 0 9 * * * means minute 0, hour 9, every day of the month, every month, every day of the week -- in plain terms, 9:00 AM daily.
The part that trips people up
Day-of-month and day-of-week are both present, and when you set both to something other than *, most cron implementations treat it as an OR, not an AND. 0 9 15 * 1 doesn't mean "the 15th, if it's also a Monday" -- it fires on the 15th of every month AND every Monday. If you only want one of those conditions, leave the other field as *.
Step and range syntax
Beyond single values, cron supports a few shorthand patterns:
*/15in the minute field means every 15 minutes1-5in the day-of-week field means Monday through Friday (cron numbers days 0-6, with 0 as Sunday)1,15in the day-of-month field means the 1st and the 15th
Combining these, */10 9-17 * * 1-5 fires every 10 minutes, between 9 AM and 5 PM, Monday through Friday -- a common pattern for business-hours polling jobs.
Timezone is not part of the expression
Cron expressions don't carry timezone information themselves. The schedule runs against whatever timezone the executing system (or scheduler service) is configured for. This catches people constantly: a job set for 0 0 * * * assuming midnight local time will fire at midnight UTC if the server is UTC-configured, which might be a very different hour where you actually are. Always check what timezone the scheduler you're using actually evaluates against before trusting a schedule.
A quick sanity check before you deploy
Because a wrong cron expression tends to fail silently -- it just runs at the wrong time, or not at all -- it's worth validating the expression before it goes anywhere near production. Reading five terse fields and mentally simulating a month of executions is exactly the kind of thing that's easy to get subtly wrong.
The Cron Expression Generator lets you build a schedule visually and see it validated, so you're not reverse-engineering asterisks by hand.