How Cron Syntax Actually Works (So You Stop Guessing)
Cron syntax looks like five random numbers and asterisks until you know what each position means, and then it stops being mysterious and just becomes slightly tedious. Most people relearn it from scratch every time they need it, because the five-minute task of writing one expression isn't enough to make the syntax stick.
This breaks down what each field actually controls, the one trap that catches almost everyone at some point, and a few real expressions translated so you can recognize the pattern next time, plus where a plain-English generator can shortcut the whole thing.
The Five Fields Cron Actually Cares About
Every cron expression has five positions, always in the same order: minute, hour, day of the month, month, and day of the week. An asterisk in any position means every value for that field. Once you know the order, even unfamiliar expressions stop looking random, they're just five answers to five questions, in a fixed sequence.
Reading a Cron Expression Without Panicking
Read left to right, one field at a time, and ask what each one restricts. A minute field of thirty means only at the thirtieth minute. An hour field of fourteen means only at two in the afternoon. Stack enough specific values across multiple fields and you get something that looks dense but is really just several simple restrictions layered on top of each other.
The Day-of-Month Plus Day-of-Week Trap
This is the one thing that catches almost everyone eventually: when both the day-of-month and day-of-week fields are restricted instead of left as an asterisk, cron treats them as an or, not an and. An expression meant to mean the fifteenth, but only if it's a Monday, actually means the fifteenth, or any Monday, running far more often than intended. If you only need one of those two restrictions, leave the other field as an asterisk.
A Few Expressions Translated
- ✓Minute zero, hour two, every day: runs once a day at two in the morning.
- ✓Minute thirty, hour fourteen, weekday field Monday through Friday: runs at two-thirty in the afternoon on weekdays only.
- ✓Minute zero, hour nine, day-of-month one: runs once a month, at nine in the morning on the first.
Once a few of these click, most new expressions are just a recombination of the same five questions.
Common Scheduling Mistakes
- ✓Forgetting that day-of-month and day-of-week combine with or, not and
- ✓Writing a schedule in local time and forgetting the server runs in UTC, or some other timezone entirely
- ✓Using a vague description like "every few hours" without picking an actual interval value
- ✓Not testing a new expression somewhere safe before pointing it at a production task
Letting a Generator Translate Plain English for You
A natural-language cron generator is a fast way to skip the five-field puzzle entirely: describe the schedule you want in plain English and get the expression back. It's especially useful for the day-of-month-versus-day-of-week trap above, since the generator handles that logic for you instead of you having to remember the exception. For double-checking an expression you wrote by hand, crontab.guru at https://crontab.guru gives a plain-English readback of exactly what an expression will do before you deploy it.
If the job you're scheduling also needs database work on a recurring basis, our SQL generator can help with the query side once the timing is sorted out.
Frequently Asked Questions
What do the five fields in a cron expression mean?▼
In order: minute (0 to 59), hour (0 to 23), day of the month (1 to 31), month (1 to 12), and day of the week (0 to 6, where 0 is Sunday). An asterisk in any field means every value, so a job set to run at every minute would have an asterisk in the first field.
Why does my cron job run more often than I expected?▼
The most common cause is restricting both the day-of-month and day-of-week fields at once. Cron combines those two fields with or rather than and, so the job runs whenever either condition is true, not just when both are.
Does cron use my local timezone?▼
Usually not. Most servers run cron in UTC or whatever timezone the system clock is set to, which is frequently not the timezone you're sitting in. Always check the system's timezone before assuming a schedule will fire at the local time you expect.
What's a safe way to test a new cron expression?▼
Use a readback tool to confirm what the expression actually means before deploying it, and where possible, run the job manually once to confirm the underlying command works before letting cron run it unattended.
Can a generator handle complex schedules like the first Monday of the month?▼
Standard five-field cron syntax cannot express first Monday directly, since it has no concept of week-of-month. Some extended cron implementations support additional syntax for this, but the more portable approach is to schedule the job to check the date itself and exit early on the days it shouldn't run.