How Cron Expressions Work (And How to Build Them)

Left to right, a standard expression looks like:

┌────── minute (0–59)
│ ┌──── hour (0–23)
│ │ ┌── day of month (1–31)
│ │ │ ┌ month (1–12)
│ │ │ │ ┌ day of week (0–7; 0 and 7 often Sunday)
│ │ │ │ │
* * * * *

• Minute — when within the hour (0 = top of the hour)
• Hour — 24-hour clock (14 = 2 PM)
• Day of month — calendar date (1–31)
• Month — 1 = January … 12 = December (some systems accept names)
• Day of week — 0–7 or names; conventions differ slightly by implementation

Minimal mental model

Think “at these minutes, on these hours, on these calendar days / weekdays.” An asterisk (*) means “every valid value for this field.” So 0 3 * * * is “minute 0, hour 3, every day, every month, any weekday” → 03:00 every day.

Paste a draft into the free cron expression generator to see a human-readable translation before you ship it.

Special characters keep expressions short.

• * — every value (every minute, every hour, …)
• , — list: 0,15,30,45 in minute = those four minutes
• - — range: 9-17 in hour = 9 through 17 inclusive
• / — step: */5 in minute = every 5 minutes; 0-30/10 = 0, 10, 20, 30

Examples

Expression	Meaning (typical 5-field)
*/10 * * * *	Every 10 minutes
0 * * * *	Every hour on the hour
30 8 * * 1-5	08:30 Monday–Friday
0 0 1 * *	Midnight on the 1st of each month
0 12 1,15 * *	Noon on the 1st and 15th

Steps are relative to the field’s range. */15 in minutes is 0, 15, 30, 45 — not “every 15 minutes from whenever the daemon started.”

Most teams live on a short list of patterns. Memorize these, then customize.

• Every minute — * * * * * (use sparingly; load and log noise)
• Every 5 minutes — */5 * * * *
• Hourly — 0 * * * *
• Daily at 02:00 — 0 2 * * *
• Weekly Sunday 04:00 — 0 4 * * 0 (confirm Sunday = 0 on your system)
• Weekdays 09:00 — 0 9 * * 1-5
• Monthly 1st at midnight — 0 0 1 * *

Business-hours style

0 9-17 * * 1-5 runs at minute 0 for hours 9 through 17 on weekdays — once per hour from 9:00 through 17:00, not “continuously.” If you need every 15 minutes only during business hours, combine a step on minutes with an hour range: */15 9-16 * * 1-5 (check whether 17:00 should be included).

Document the intended plain-English schedule next to the string in your repo. Six months later, 7 3 * * 2 is not self-explanatory.

This is the sharp edge of cron. Many Vixie-cron-style implementations treat non-* values in both day-of-month and day-of-week as OR: the job runs when either field matches. Other systems document AND or reject dual constraints. Read your platform docs before you set both.

Safe patterns

• Calendar date only: day-of-week = * — e.g. 0 6 15 * * = 06:00 on the 15th
• Weekday only: day-of-month = * — e.g. 0 6 * * 1 = 06:00 every Monday

Risky pattern

0 6 15 * 1 may mean “06:00 on the 15th or on Mondays” on classic cron — not “Mondays that are also the 15th.” If you need “first Monday of the month,” plain 5-field cron is awkward; many teams use a daily job plus a guard in code, or a scheduler with richer calendars.

When debugging “why did this fire today?”, log the fire time as a Unix timestamp and convert it with a timestamp converter so local vs UTC confusion does not hide the real schedule bug.

Cron fields describe clock faces on the machine (or container) timezone unless the product says otherwise. A job at 0 9 * * * is 09:00 in that environment’s local zone — which may be UTC in production and America/New_York on your laptop.

• Containers — image default is often UTC; set TZ deliberately
• Managed cron — AWS EventBridge, GCP Cloud Scheduler, and others let you pick a zone per rule
• DST — “every day at 2:30 local” can skip or repeat an hour when clocks change; prefer UTC for critical finance-style jobs when possible

Six-field and seven-field variants

Some libraries add seconds on the left (0 0 9 * * * style) or year on the right. Never paste a 6-field string into a 5-field crontab without checking. Quartz-style day-of-week numbering can also differ from classic crontab.

If you store schedules in config JSON, keep the expression and timezone as separate fields and validate JSON with a JSON formatter before deploy.

Generators reduce off-by-one mistakes and make expressions reviewable in pull requests.

1. Open the free cron expression generator.
2. Pick minute and hour for the fire time (or a step like every 15 minutes).
3. Leave day/month as every unless you need a calendar constraint.
4. Set day-of-week for weekday-only or weekly jobs; keep the other day field as * when possible.
5. Read the human-readable translation aloud — does it match the ticket?
6. Copy the expression into crontab, CI, or your orchestrator.
7. Confirm the runtime timezone matches the intended local clock.
8. After first deploy, watch one or two fire events and compare to expected wall times.

Code review checklist

Ask: Is this UTC or local? Does anything else lock the same resource at this minute? Should failure alert within N minutes? Pair schedule strings with job names and owners in the same config file.

Small syntax errors create large operational surprises.

• Hour 0 vs 12 confusion — 0 is midnight; 12 is noon
• Forgetting minute field — 5 * * * * is “minute 5 every hour,” not “every 5 minutes”
• Every-minute jobs in production without rate limits or idempotency
• Dual day fields without knowing OR vs AND behavior
• Assuming laptop timezone equals production
• Copy-pasting Quartz/6-field into 5-field crontab

When validating free-form strings or log patterns around jobs, a regex tester guide helps. For opaque IDs in job payloads, see the UUID generator guide. Timestamp debugging pairs with the timestamp converter guide.

This guide is educational. Always match the expression dialect and timezone rules of the system that will actually run the job.