If you have ever needed a script to run automatically every night, a report to be emailed every Monday morning, or a cache to be cleared every five minutes, you have run into cron. Cron is the time-based job scheduler that quietly powers an enormous amount of the automation on Unix and Linux systems. The catch is that cron describes schedules using a terse five-field string that looks like line noise the first time you see it. This guide demystifies cron expressions step by step, walks through the fields and special characters, shows worked examples, and points you to a free tool that translates any expression into plain English.
What Is Cron and Where Is It Used?
Cron is a scheduling daemon that runs in the background on Unix-like operating systems. It reads a configuration file called a crontab (short for cron table), and at the right moment it runs whatever command each line specifies. Because it has been a standard part of Unix since the 1970s, the same basic syntax shows up almost everywhere automation lives.
You will find cron expressions in server crontabs, of course, but also in Docker containers, CI/CD pipelines, Kubernetes CronJobs, cloud schedulers like AWS EventBridge and Google Cloud Scheduler, and application frameworks that need to run recurring background tasks. Learning to read a cron expression is a skill that pays off across all of these environments, because the five-field format is broadly shared even when the surrounding tooling differs.
The Five Fields
A standard cron expression has five fields separated by spaces, and the order never changes. From left to right they are: minute, hour, day of month, month, and day of week.
The minute field accepts values from 0 to 59. The hour field uses a 24-hour clock from 0 to 23, so there is no AM or PM. The day-of-month field runs from 1 to 31. The month field runs from 1 to 12, where 1 is January, and many cron implementations also accept three-letter names like JAN through DEC. The day-of-week field runs from 0 to 6, where 0 is Sunday, and most implementations accept names like SUN through SAT as well. Note that some systems also treat 7 as Sunday for convenience.
A value in each position tells cron when that part of the schedule should fire. When every field matches the current time, the command runs.
The Special Characters
Four special characters do almost all the work in cron expressions, and once you know them you can read most schedules at a glance.
The asterisk means any value, or every value. An asterisk in the hour field means every hour. The comma builds a list, so 1,15,30 in the minute field means at minute 1, minute 15, and minute 30. The hyphen defines a range, so 1-5 in the day-of-week field means Monday through Friday. The slash defines a step, so */5 in the minute field means every fifth minute, and it can be combined with a range, as in 0-30/10, which means every ten minutes within the first half of the hour.
These four characters combine freely across fields, which is what gives cron its flexibility.
Worked Examples
The fastest way to internalize cron is to read real expressions out loud. Consider the expression */5 * * * *. The first field, */5, means every five minutes, and the four asterisks mean every hour, every day, every month, and every day of the week. So this runs every five minutes, all the time.
The expression 0 0 * * * runs at minute 0 of hour 0, which is midnight, every day. It is the classic daily-at-midnight job. The expression 0 9 * * 1-5 runs at minute 0 of hour 9, which is 9am, but only on days of the week 1 through 5, which is Monday through Friday. That is a typical weekday-morning schedule. Finally, the expression 0 0 1 * * runs at midnight on day 1 of the month, every month, which is the standard first-of-the-month job.
The Day-of-Month vs Day-of-Week Gotcha
One of the most surprising parts of cron is how the day-of-month and day-of-week fields interact. You might expect that restricting both fields would narrow the schedule, but in most cron implementations the two day fields are combined with a logical OR, not an AND, whenever both are set to something other than an asterisk.
Consider the expression 0 0 1 * 1. You might read it as midnight on the first of the month, but only if it is also a Monday. In practice, most cron daemons run this job at midnight on the first of every month and also at midnight on every Monday. The job fires if either day condition matches. To avoid confusion, the safe habit is to leave one of the two day fields as an asterisk unless you genuinely want the OR behavior, and to test the expression before relying on it.
Timezone and Seconds Caveats
Two caveats trip up newcomers more than any others. The first is timezones. Traditional cron runs in the local time of the server it lives on, not in your timezone and not in UTC by default. If your server clock is set to UTC but you think in Pacific time, a job scheduled for 0 9 will run at 9am UTC, which is the middle of the night for you. Always confirm the server timezone, and prefer setting servers to UTC so schedules are predictable. Daylight saving transitions add further surprises, since a job scheduled in the skipped or repeated hour may be skipped or run twice.
The second caveat is seconds. Standard cron has no seconds field, so the finest granularity you can express is one minute. Some modern schedulers, such as Quartz, Kubernetes tooling, and various language libraries, add a sixth field at the front for seconds, which shifts every other field one position to the right. If an expression has six fields, check the documentation, because the leading field is almost certainly seconds rather than minutes.
Tips for Avoiding Mistakes
A few habits prevent most cron errors. Read each expression field by field, left to right, and say what each one means before trusting it. Remember that hours use a 24-hour clock, so 13 is 1pm and there is no way to write a 12-hour time with AM or PM. Be deliberate about the two day fields and the OR behavior described above. When you want a job at a specific minute, set the minute field explicitly rather than leaving it as an asterisk, because an asterisk in the minute field means the job runs every single minute of the matching hour, which is rarely the intent.
Finally, test before you deploy. A schedule that is off by one field can mean a job that never runs or one that hammers your system sixty times an hour. Confirming the next few run times in advance catches these mistakes before they reach production.
Translate Any Expression with ToolboxHub
When you just want to know what an expression does without parsing it by hand, the free ToolboxHub Cron Expression Explainer does the work for you. Paste an expression like 0 9 * * 1-5 and it translates it into plain English, telling you it runs at 9:00 AM, Monday through Friday. It breaks down each of the five fields so you can see exactly which minute, hour, day, month, and weekday the schedule covers, and it helps you catch mistakes before they ship.
The tool runs entirely in your browser, so nothing you paste is sent to a server, and there is no sign-up or limit. It pairs well with the Timestamp Converter when you are reasoning about when a job last ran, and with the Timezone Converter when you need to translate a server-local schedule into your own local time.
Key Takeaways
A cron expression is five space-separated fields in a fixed order: minute, hour, day of month, month, and day of week. Four special characters carry the meaning, where the asterisk is any value, the comma builds a list, the hyphen defines a range, and the slash defines a step. Read expressions field by field, and remember the everyday patterns: */5 * * * * runs every five minutes, 0 0 * * * runs daily at midnight, 0 9 * * 1-5 runs at 9am on weekdays, and 0 0 1 * * runs on the first of every month. Watch the day-of-month versus day-of-week OR behavior, confirm your server timezone, and know that standard cron has no seconds field while some schedulers add a sixth. When in doubt, let the free ToolboxHub Cron Expression Explainer translate the schedule into plain English so you can verify it at a glance.