Intro
A cron expression describes the times that a scheduler may start a job. The catch is that “cron” is a family of related syntaxes, not one universal format. A five-field expression that is valid in a Unix crontab can be the wrong shape for an application scheduler that expects seconds first.
Before deploying a schedule, identify the scheduler, its time zone, its day-field rule, and what it does after a missed or slow run. The expression is only one part of a reliable job.
Traditional five-field crontab
A traditional Unix user crontab has five time fields followed by the command:
minute hour day-of-month month day-of-week command
Cronie's crontab(5) manual documents these ranges:
- Minute: 0–59.
- Hour: 0–23.
- Day of month: 1–31.
- Month: 1–12; names may also be supported.
- Day of week: 0–7, where 0 and 7 are Sunday; names may also be supported.
An asterisk (*) selects every value in that field. A comma is a list, a hyphen is an inclusive range, and a slash applies a step within the preceding range.
Read common expressions precisely
- 0 9 * * 1-5: 09:00 every Monday to Friday.
- */15 * * * *: minute 0, 15, 30, and 45 of every hour.
- 0 0 1 * *: 00:00 on the first day of each month.
- 23 0-23/2 * * *: 00:23, 02:23, 04:23, and so on.
Steps restart with the field's range; they are not elapsed-time timers. In traditional cron, */35 in the minute field runs at minute 0 and minute 35 of each hour. It does not wait 35 minutes after the previous run. If an exact elapsed interval matters, use a scheduler designed for interval scheduling or make the job tolerate a variable gap.
The NAB Tools Cron Generator can make a five-field draft, but compare the result with the documentation for the scheduler that will run it.
Five, six, and seven fields are not interchangeable
Traditional crontab uses the five fields above. Other schedulers borrow the name “cron” but change the format or operators. Quartz CronTrigger, for example, adds a leading seconds field and supports an optional trailing year field; it also uses operators such as ?, L, W, and # that are not traditional crontab syntax.
The expression 0 0 9 ? * MON-FRI is a Quartz-style schedule, not a five-field Unix crontab entry. Conversely, adding a leading 0 to a five-field expression can move every field one place to the right in a scheduler that was already expecting five. Do not infer compatibility from the number of fields alone: check the product's schedule reference and preview the next occurrences there.
The day-of-month and day-of-week trap
In Cronie, if both day-of-month and day-of-week are restricted, the job runs when either one matches. For example, 0 9 1 * 1 means 09:00 on the first day of every month and at 09:00 every Monday. It does not mean “the first Monday of the month.” Use 0 9 1 * * for the first day of the month, or 0 9 * * 1 for Mondays.
This rule is a portability hazard: other schedulers document different day-field behavior or require a placeholder such as ?. Check the target scheduler rather than relying on a remembered convention. Sunday numbering is another common difference, although Cronie accepts both 0 and 7 for Sunday.
Time zones, daylight saving, and missed work
Cronie evaluates the crontab in the daemon's local time unless the table uses its supported CRON_TZ setting. A hosted scheduler may instead default to UTC or expose a separate time-zone setting. Write the intended zone down, set it explicitly when the platform allows it, and test it with a future occurrence around a daylight-saving transition. The related UTC, GMT, and daylight-saving guide explains the distinction between a time-zone rule and an offset.
For Cronie, a local time that does not exist during a daylight-saving change is not matched, while a local time that occurs twice can run twice. A scheduler may also skip, delay, retry, or backfill a run after downtime; that is scheduler policy, not something the five fields answer.
If a job can run longer than its schedule interval, decide how to prevent duplicate work. A lock, queue, or idempotent operation can make an accidental second execution safe. Monitoring should report both a failed run and a run that never started.
Production checks that prevent surprises
- Translate the expression into plain English and list the next few expected run times.
- Validate it in the actual scheduler. Cronie provides crontab -T for syntax testing; other schedulers have their own validation or preview.
- Set the execution time zone and confirm what daylight-saving changes do on that platform.
- Use absolute paths and set the required environment deliberately. A Cronie command is run by /bin/sh unless SHELL is set.
- Escape or avoid an unquoted percent sign in a traditional crontab command: Cronie turns an unescaped % into a newline and passes the remainder to standard input.
- Define a timeout, overlap policy, retry behavior, logs, and an alert for a missed or failed job before it performs an irreversible action.
For jobs that pass time values between systems, use the NAB Tools Unix Timestamp Converter to verify the instant separately from the schedule. That helps catch a correct-looking cron expression interpreted in the wrong zone.
Practical takeaway
Use five fields only when the target really is a traditional crontab. For every other scheduler, start from its documentation, then test the exact expression, zone, and failure behavior before production use.
FAQ
Are cron expressions five or six fields?
Traditional Unix crontab uses five time fields. Some schedulers add seconds as a leading sixth field, and Quartz also supports an optional year field. The scheduler's documentation decides which form is valid.
Does */35 mean every 35 minutes?
Not in traditional cron. It matches minute 0 and minute 35 in each hour, so the gap alternates between 35 and 25 minutes.
How do I schedule the first Monday of a month?
Do not assume that restricting both day fields means “and.” In Cronie it means either field can match. Use a scheduler with an explicit first-weekday feature, or schedule Mondays and make the job check the date before doing its work.
Can the same cron expression work everywhere?
No. Field order, supported operators, time-zone defaults, day-field logic, retry behavior, and missed-run behavior all vary by scheduler.