Cron Syntax for Beginners

A standard cron expression is five fields separated by spaces: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, where 0 is Sunday). Each field answers 'on which values should this run?' A literal number means exactly that value; an asterisk means every value. So 0 9 * * * reads as 'at minute 0 of hour 9, every day, every month, every weekday' — 9:00 AM daily.

Four operators cover almost everything else. A comma lists values (0,30 = on the 0th and 30th minute); a hyphen makes a range (1-5 in the day-of-week field = Monday through Friday); and a slash sets a step (*/15 in the minute field = every 15 minutes). Combine them freely: 0 9-17 * * 1-5 is 'every hour on the hour from 9 AM to 5 PM, Monday to Friday.' Reading a cron line is just translating each field in order.

A handful of shapes cover most real jobs. Every fifteen minutes is */15 * * * *. Every day at 2:30 AM is 30 2 * * *. The top of every hour is 0 * * * *. Weekdays at 9 AM is 0 9 * * 1-5. The first of every month at midnight is 0 0 1 * *. Once you can read the five fields, you mostly assemble these from memory rather than deriving them each time.

Where beginners slip is over-specifying or mis-ordering. A common bug is scheduling '0 0 * * *' expecting hourly and getting once-a-day, because the first field is minute, not 'every.' Another is forgetting that cron has no 'seconds' field in the standard five-field form — the finest granularity is one minute. When a pattern doesn't behave, translate it field by field before assuming the scheduler is wrong.

The classic gotcha: when you set both day-of-month and day-of-week to specific values, most cron implementations treat them as OR, not AND. So 0 0 13 * 5 does not mean 'Friday the 13th' — it means 'every 13th of the month AND every Friday,' running far more often than you expect. If you need a specific weekday, leave day-of-month as * (and vice versa); getting both to cooperate requires a check inside your job, not cron alone.

The second trap is timezone. Cron runs in the server's configured timezone, which is frequently UTC on cloud hosts — so 0 9 * * * fires at 9 AM UTC, not 9 AM where you live, and can land on the 'wrong' calendar day. Daylight-saving transitions add edge cases where a job is skipped or repeated. Before trusting a schedule, confirm the server's timezone and, if it matters, express your times in that zone or use a scheduler that supports an explicit TZ.