Cron Syntax Cheatsheet: How to Read Any Crontab Schedule

Every cron schedule — whether it's a Linux crontab entry, a Kubernetes CronJob, or a GitHub Actionsschedule trigger — follows the same five-field format. Once you know the order, reading any expression is just pattern matching.

The five fields, in order

┌───────────── minute (0-59)
│ ┌───────────── hour (0-23)
│ │ ┌───────────── day of month (1-31)
│ │ │ ┌───────────── month (1-12)
│ │ │ │ ┌───────────── day of week (0-6, Sunday=0)
│ │ │ │ │
* * * * *

Every field is either a specific value, a wildcard, or one of a few special characters. Mixing those up — especially the last two fields — is the single most common source of "why didn't this run when I expected" bugs.

The special characters

Common patterns, decoded

The gotcha: day-of-month AND day-of-week together

When both the day-of-month and day-of-week fields are restricted (i.e. neither is *), most cron implementations run the job if either condition matches — not both. So0 0 15 * 1 ("midnight on the 15th, OR every Monday") will fire on both the 15th of the month and every Monday, which surprises almost everyone the first time they hit it. If you only want the 15th specifically, leave day-of-week as *.

A note on time zones

Cron expressions don't carry a time zone — they run in whatever time zone the executing system (or platform) is configured for. A server crontab typically runs in the machine's local time or UTC depending on its config; GitHub Actions schedules always run in UTC regardless of where you are. Always confirm the executing environment's time zone before trusting a schedule against wall-clock time, especially around daylight saving transitions.

Try it yourself

Paste any expression into the Cron Expression Parser to see it translated into plain English instantly — faster than working through the five fields by hand, and a good sanity check before you ship a schedule to production.