Cron Expressions Guide: Syntax and Common Patterns

Cron is the scheduling language used by Unix-like systems and countless task runners to decide when a job should fire. A classic cron expression has five fields, separated by spaces, read left to right: 1. Minute (0–59) 2. Hour (0–23) 3. Day of month (1–31) 4. Month (1–12) 5. Day of week (0–6, where 0 is Sunday) So the expression 30 9 * * 1 means "at 09:30, on Monday." Each field answers one question, and a job runs only when the current time matches every field. Reading cron by eye is error-prone, which is why it helps to build and check expressions with the cron expression builder. It translates a pattern into plain English and previews the next run times, so you catch mistakes before they reach production.

Four symbols give cron its flexibility, and almost every schedule is built from them. The asterisk (*) means "every value" for that field. In the minute field it means every minute; in the month field it means every month. The slash (/) defines steps. Writing */5 in the minute field means "every 5 minutes" — that is, 0, 5, 10, and so on. You can combine it with a range, so 0-30/10 means every ten minutes in the first half hour. The comma (,) lists specific values. In the hour field, 9,12,17 means "at 9, at 12, and at 17." The hyphen (-) defines an inclusive range. In the day-of-week field, 1-5 means Monday through Friday. These combine freely. The expression */15 9-17 * * 1-5 reads as "every 15 minutes, between 9am and 5pm, Monday to Friday." When a job logs a Unix timestamp you want to read back, the timestamp converter turns those epoch seconds into a human date.

Most real-world schedules fall into a handful of shapes. Here are dependable patterns to adapt: Every 5 minutes: */5 * * * * Every hour on the hour: 0 * * * * Every day at midnight: 0 0 * * * Weekdays at 9am: 0 9 * * 1-5 The first of every month at 02:00: 0 2 1 * * Every Sunday at 23:30: 30 23 * * 0 A classic trap involves the two "day" fields. When you specify both day-of-month and day-of-week, traditional cron treats them as an OR, not an AND — so "0 0 13 * 5" runs on the 13th and on every Friday, not only on Friday the 13th. If you only need one, leave the other as an asterisk. Always confirm the interpretation with the cron expression builder before deploying.

Timing bugs in scheduled jobs almost always come down to timezones, and they are sneaky because the cron syntax itself says nothing about zones. Cron uses the system clock. A traditional crontab runs against the server's local timezone. If your laptop is in London but the server is set to UTC, a "0 9 * * *" job fires at 9am UTC, which may be 10am or 8am for you depending on the season. Daylight saving time creates gaps and duplicates. When clocks spring forward, a job scheduled for a skipped hour may not run at all that day; when clocks fall back, a job in the repeated hour may run twice. For anything sensitive, schedule outside the 1am–3am window where these shifts happen. Managed schedulers often accept an explicit timezone. Cloud cron services and many job frameworks let you attach a zone to the expression, which removes the ambiguity entirely — prefer that when available. To reason about what a server-time schedule means for users elsewhere, convert between zones with the timezone converter. Follow this checklist: confirm the host timezone, decide whether the schedule should follow users or the server, avoid the DST transition hours, and document the intended zone next to the expression. One last habit pays off repeatedly: after deploying a schedule, watch the first few real runs in your logs rather than trusting the expression on paper. A pattern that looks right can still misfire because of a timezone, a missing leading zero, or the day-field OR rule, and the logs reveal it immediately. Treat the expression as code: keep it in version control with a comment explaining its intent, so the next person does not have to decode the asterisks from scratch.