Reading Cron Fluently

Every engineer has pasted a cron expression without fully understanding it. You found a Stack Overflow answer, copied 0 */4 * * *, and moved on. It works - until it doesn't, and now you need to reason about it under production pressure.

Reading cron fluently means parsing the five-field format instantly, without counting fields on your fingers. It is a small skill with an outsized payoff.

The anatomy of a cron expression

┌── minute       (0–59)
│  ┌── hour      (0–23)
│  │  ┌── day of month (1–31)
│  │  │  ┌── month      (1–12 or JAN–DEC)
│  │  │  │  ┌── day of week (0–6, Sun=0 or 7)
│  │  │  │  │
*  *  *  *  *

Five positions. Read them left to right: sub-hour, then hour, then day, then month, then weekday. A * in any position means "every valid value" for that field.

A reading heuristic

Start from the right and scan left until you hit the first non-* field. That field is the outermost scheduling granularity; everything to its left refines it.

• * * * * * - every minute of every day
• 0 * * * * - top of every hour
• 0 9 * * * - 09:00 every day
• 0 9 * * 1-5 - 09:00 Monday through Friday
• 0 9 1 * * - 09:00 on the first of every month
• 0 9 1 1 * - 09:00 on January 1st

Special characters

The / step character trips people up most often. */15 in the minute field does not mean "at minute 15" - it means "at every minute divisible by 15": 0, 15, 30, 45. Similarly, 2/15 means "starting at minute 2, every 15 minutes thereafter": 2, 17, 32, 47.

The five traps

1. Day-of-week numbering is inconsistent. Standard cron treats both 0 and 7 as Sunday. AWS EventBridge uses 1 for Sunday. GitHub Actions follows standard cron. Always verify which convention your platform uses.

2. Day-of-month and day-of-week are OR'd, not AND'd. On most cron implementations, 0 9 1 * 1 fires at 09:00 on the first of the month or on any Monday - not only on Mondays that happen to be the 1st. If you want the intersection, you need a different approach (a wrapper script that checks both conditions).

3. Months are 1-indexed but weekdays are 0-indexed. January is 1, Sunday is 0. This asymmetry causes bugs when copy-pasting examples.

4. / steps start at the field's minimum, not at zero. 1/2 in the hour field fires at 1, 3, 5, 7 ... - not at 0, 2, 4. This distinction matters for aligning jobs to the hour boundary.

5. The timezone is set on the daemon, not in the expression. A cron expression carries no timezone information. The same expression fires at different UTC times in different environments. Always document the timezone alongside the expression, and set it explicitly in your scheduler (crontab's CRON_TZ, Kubernetes CronJob's .spec.timeZone, etc.).

Patterns you'll read every week

# Nightly at 2 AM
0 2 * * *
 
# Every 5 minutes during business hours, weekdays
*/5 9-17 * * 1-5
 
# First day of each month at midnight
0 0 1 * *
 
# Every 15 minutes
*/15 * * * *
 
# Weekdays at 8 AM UTC (for a 9 AM BST job - write it down)
0 8 * * 1-5
 
# Quarterly: first day of Jan, Apr, Jul, Oct at noon
0 12 1 1,4,7,10 *

Building confidence

The fastest way to internalize cron is to explain expressions out loud, then check your reading with a tool. Use the Cron Explainer to see the next five run times alongside a plain-English description. Run a few variants of an expression before you deploy - catching a misconfigured step value in a tool is much cheaper than debugging a misfired job at 3 AM.

Once you can read */5 9-17 * * 1-5 as "every five minutes, between 9 AM and 5 PM, on weekdays" without pausing, cron stops being a paste-and-pray format and becomes a concise scheduling language you can reason about confidently.