A cron expression is made from five space-separated fields—minute, hour, day of month, month, and day of week—that tell a traditional Unix-style scheduler when a job should run. To create one from a readable schedule, choose a preset in the Cron Expression Generator, adjust the controls it presents for that frequency, and copy the resulting five-field expression. The tool supports every minute, every N minutes, hourly, daily, weekdays, weekly, and monthly schedules, then shows both the expression and a plain-English summary as you work. That approach is useful when you know the job’s timing but do not want to translate it by hand into values for each field. The generated expression describes timing only: it does not include the command, user, environment variables, retries, locking, or monitoring. Generation happens locally, so neither the selected schedule nor the command is uploaded. Before deployment, still confirm that the destination accepts standard five-field cron, check the scheduler’s configured time zone, and test the schedule outside production. Hosted schedulers may add fields or vendor-specific syntax, and daylight-saving changes can affect local wall-clock execution.
What the five fields actually mean
Traditional cron syntax depends on field order as well as field values. The position of each value tells the scheduler what it controls, so moving a value into the wrong position can change the intended schedule. The standard field order and value ranges follow the Linux crontab(5) manual.
| Position | Field | Standard range | What it controls |
|---|---|---|---|
| 1 | Minute | 0–59 | The minute within each hour |
| 2 | Hour | 0–23 | The hour of the day |
| 3 | Day of month | 1–31 | The numbered day within a month |
| 4 | Month | 1–12 | The month of the year |
| 5 | Day of week | 0–6 | The weekday, from Sunday 0 through Saturday 6 |
Three syntax elements cover most schedules built with the generator:
- Asterisk: * means every valid value for that field.
- Slash: A slash introduces a step, as used by an every-N-minutes schedule.
- Inclusive range: A range such as 1-5 covers Monday through Friday when it appears in the day-of-week field.
Be careful when both day-of-month and day-of-week are restricted. Some cron implementations apply surprising OR-like behavior in that situation, meaning the job may run when either field matches. The generator’s included presets avoid setting both fields at the same time, which keeps common schedules predictable across the target scheduler.
Choose a schedule and generate the expression
Use the generator as a schedule-to-expression workflow rather than trying to assemble all five positions at once.
- Choose the schedule type that matches the job frequency. Select every minute, every N minutes, hourly, daily, weekdays, weekly, or monthly. Choosing the closest preset first reduces the number of fields you need to think about and keeps the generated expression within the supported five-field format.
- Set the interval, minute, hour, weekday, or month-day control shown for that schedule. An every-N-minutes preset uses an interval, while hourly, daily, weekdays, weekly, and monthly presets expose the relevant time or calendar controls. Minutes remain between 0 and 59, hours between 0 and 23, weekdays between Sunday 0 and Saturday 6, and month days between 1 and 31. Watch the five-field expression and plain-English summary update immediately so you can compare the machine-readable result with your intended timing.
- Copy the expression and verify the target scheduler and time zone. Confirm that the destination accepts standard five-field cron rather than a six-field, seven-field, or vendor-specific dialect. Check the scheduler’s configured time zone, add the command separately in the target crontab or job scheduler, and test the configuration in a non-production environment before relying on it.
The final step matters because a syntactically valid expression can still be scheduled differently by different systems. The expression identifies matching times; it does not select the scheduler’s time zone or define what the job should do when it runs.
Compare the common schedule types
Choose the schedule that reflects the business rule rather than selecting fields independently. These are the seven common presets and the timing each one represents.
| Schedule preset | Use it when | Relevant setting | Timing represented |
|---|---|---|---|
| Every minute | The job must be considered once per minute | Select the preset | Every valid minute |
| Every N minutes | The job follows a fixed minute step | Interval | A clock-aligned step in the minute field |
| Hourly | The job runs at the same minute each hour | Minute | A fixed minute within every hour |
| Daily | The job runs once at a particular time each day | Minute and hour | The selected time every day |
| Weekdays | The job follows a Monday-through-Friday pattern | Minute, hour, and weekday | The selected time on weekdays |
| Weekly | The job runs on one chosen weekday | Minute, hour, and weekday | The selected time each week |
| Monthly | The job runs on a chosen calendar date | Minute, hour, and month day | The selected date each month, subject to month length |
An every-N-minutes cron schedule represents a clock-aligned step, not a guarantee that the scheduler waits N minutes after the previous command finishes. If the job’s runtime varies and the gap must begin after completion, use a scheduler designed for that behavior rather than relying on the cron expression alone.
Decode one practical weekday schedule
Consider a job that must run at 09:00 from Monday through Friday. Its standard five-field cron expression is 0 9 * * 1-5.
- 0 selects minute zero of the hour.
- 9 selects 09:00 in the scheduler’s time zone.
- * permits every valid day of the month.
- * permits every valid month.
- 1-5 is an inclusive weekday range covering Monday through Friday.
The plain-English interpretation is “At 09:00, Monday through Friday.” Notice that only the day-of-week field is restricted. The day-of-month and month fields remain wildcards, avoiding the implementation-specific behavior that can appear when both calendar-day fields are constrained. The generator produces this same kind of bounded, standard expression without requiring you to arrange the fields manually.
Account for time zones and scheduler dialects
Check the scheduler’s time zone
A cron job follows the time zone configured in the scheduler, which may not be the time zone shown on your computer. Daylight-saving transitions can also skip or repeat a local wall-clock time, depending on the transition and the scheduler’s implementation. If the intended schedule must be tied to UTC, configure the target scheduler accordingly rather than assuming the local computer setting will be used. The standard five-field expression itself has no time-zone field.
Plan for shorter months
A monthly job scheduled for day 29, 30, or 31 does not run in months that do not contain that date. This is calendar reality rather than a syntax error. If the job must run every month, select a day that exists in every month; if it must use a particular date, decide separately how omitted runs should be reported.
Confirm the accepted syntax
Some hosted schedulers accept six or seven fields, additional seconds or years, question marks, or vendor-specific extensions. Those formats may look similar to traditional cron but are not interchangeable with a standard five-field expression. Use the generator output as the timing portion, then confirm that the target accepts that exact format. Do not add extra fields or special tokens unless the target documentation explicitly requires them.
Turn the expression into a safe scheduled job
After copying the expression, add the command in the target crontab or scheduler. A traditional crontab entry may also require a user field, but the generated expression does not include one. Environment variables, working directories, and command arguments belong in the scheduler’s job definition rather than inside the five timing fields. For a traditional Linux workflow, follow the steps for creating a cron job in Linux after the schedule has been generated.
Test the complete entry in a non-production environment and observe the scheduler’s time zone, logs, and actual run time. If retries or overlapping runs are possible, use an idempotent command so repeated execution does not cause unwanted duplicate effects. Logging failures gives you a way to distinguish “the job did not run” from “the job ran but failed.” The cron expression controls when execution is attempted; retries, locking, environment setup, and monitoring still need to be handled by the surrounding system.
For a deeper look, see Cron Parser Explained: Fields, Rules, and Next Runs.