A cron expression tells a scheduler when to run a command using five fields: minute, hour, day of month, month, and day of week. To run a task every weekday at 9:00 AM, use the expression 0 9 * * 1-5. This triggers the command at exactly 9:00 AM from Monday through Friday, excluding weekends.
Understanding the Cron Expression Structure
A standard cron expression consists of five space-separated fields. Each field controls a specific part of the timing logic. If you leave a field blank or use an asterisk (*), the scheduler interprets it as "every valid value" for that position.
The order is strict: minute, hour, day of month, month, day of week. For example, 0 9 * * 1-5 breaks down as follows: the minute is 0, the hour is 9, the day of month is * (every day), the month is * (every month), and the day of week is 1-5 (Monday through Friday).
Misunderstanding the day-of-week field is common. In most cron implementations, Sunday is 0 or 7, Monday is 1, and Friday is 5. Using 1-5 explicitly excludes Sunday and Saturday, ensuring your job runs only on business days. If you need Saturday included, you would change the range to 1-6 or list specific days like 1,2,3,4,5,6.
Writing Your First Cron Schedule
Let’s build the weekday morning report schedule step by step. Start with the minute field. You want the job to start exactly on the hour, so set the minute to 0. Next, set the hour to 9. This locks the time to 9:00 AM.
Now handle the date constraints. Leave the day-of-month field as * because you want the job to run regardless of whether it’s the 1st or the 15th of the month. Do the same for the month field, using * to ensure it runs in January and July alike.
Finally, restrict the day of week. Enter 1-5 to cover Monday through Friday. The final expression is 0 9 * * 1-5. When you paste this into a scheduler, it will trigger at 09:00 on Monday, Tuesday, Wednesday, Thursday, and Friday. It will skip Saturday and Sunday entirely.
Verifying Timing with Next-Fire Previews
Manual calculation of cron times is error-prone, especially across time zones or daylight saving changes. Instead of guessing, use a next-fire preview tool to see exactly when your schedule will trigger next. This confirms that your logic matches your intent before you deploy.
For the expression 0 9 * * 1-5, a preview shows the upcoming ten firing times in your local timezone. If today is Wednesday, the list might look like this:
Wed 09:00 AM
Thu 09:00 AM
Fri 09:00 AM
Mon 09:00 AM
Tue 09:00 AM
Wed 09:00 AM
Thu 09:00 AM
Fri 09:00 AM
Mon 09:00 AM
Tue 09:00 AMNotice that Saturday and Sunday are absent from the list. This visual confirmation ensures your 1-5 range works as expected. If you see Saturday included, check if your scheduler treats Sunday as 0 or 7 differently, or if you accidentally used 0-5. A preview removes ambiguity without requiring you to wait until the next week to test.
You can use CronExplain to paste your expression and immediately see these next ten firing times alongside a plain-English explanation. This saves time compared to mentally calculating offsets for each weekday.
Using the Visual Builder for Complex Schedules
Writing cron expressions from memory often leads to syntax errors or logical mistakes. A visual builder lets you construct schedules by selecting values from dropdowns for minute, hour, day, month, and weekday. As you change selections, the resulting cron string updates live, allowing you to see how each choice affects the schedule.
For instance, if you need a job to run every five minutes during business hours only, you can set the minute field to */5, the hour to 9-17, and keep the day-of-week as 1-5. The builder generates */5 9-17 * * 1-5. You can verify this by checking the preview: the job fires at 9:00, 9:05, ..., up to 17:55, but skips evenings and weekends.
This method is faster than typing syntax from scratch. You avoid common pitfalls like forgetting spaces between fields or misunderstanding ranges. Once satisfied, copy the generated expression into your crontab file or CI/CD configuration.
Handling Common Cron Patterns and Nicknames
Many common schedules have shorthand nicknames supported by Vixie cron and similar implementations. These nicknames simplify readability but behave identically to their expanded forms. Knowing them helps you interpret existing configurations quickly.
| Nickname | Equivalent Expression | Description |
|---|---|---|
@hourly | 0 * * * * | Runs once per hour at minute 0. |
@daily | 0 0 * * * | Runs once per day at midnight. |
@weekly | 0 0 * * 0 | Runs once per week on Sunday at midnight. |
@monthly | 0 0 1 * * | Runs once per month on the 1st at midnight. |
@yearly | 0 0 1 1 * | Runs once per year on January 1st at midnight. |
Note that @weekly uses Sunday (0) by default in many systems. If your organization runs on Monday mornings, avoid @weekly and use 0 9 * * 1 instead. Also, some systems support a six-field format with seconds at the beginning, such as 0 */5 * * * * for every five minutes. Always check which flavor your scheduler supports. Quartz schedulers, for example, do not support the @ nicknames and require full expressions.
Deploying and Testing Your Cron Jobs
Once your expression is validated, add it to your deployment configuration. In a Linux crontab, you edit the file with crontab -e and append your line. For Kubernetes, you add the schedule to a CronJob resource. In GitHub Actions, you place it under the schedule key.
After deploying, monitor the first few executions. Check logs to confirm the job starts at the expected minute and hour. If the job runs too frequently, check if you used * instead of a specific minute value. If it skips days, verify your day-of-week range matches your calendar assumptions.
Testing in staging before production prevents unexpected load spikes. For example, if you mistakenly set * * * * * instead of 0 * * * *, your job runs every minute instead of every hour. A quick preview check catches this before deployment. Once confirmed, your schedule is ready for steady operation.