Cron Syntax Explained

Cron is a scheduling system commonly used on Unix-like operating systems to run commands and scripts automatically at specified times. Instead of manually starting a task, you can define a schedule using a compact cron expression and let the system execute the command whenever the schedule matches the current time.

Cron syntax looks simple once its structure is understood, but the individual fields and special characters can be confusing at first. A typical cron expression contains five time fields representing the minute, hour, day of the month, month, and day of the week. Each field accepts values, ranges, lists, and step expressions.

What Is a Cron Expression?

A cron expression is a text-based schedule that describes when a recurring task should run. The traditional Unix cron format contains five fields separated by spaces.

30 2 * * *

This expression means that the task should run at 02:30 every day. The five fields are interpreted from left to right according to a fixed order.

In the day-of-week field, 0 and 7 commonly represent Sunday. Some cron implementations also accept names such as MON or FRI, while others may provide additional syntax beyond the traditional five-field format.

The Five Cron Fields

The easiest way to understand a cron expression is to read each field independently. For example:

15 8 * * 1

The first field, 15, means minute 15. The second field, 8, means 08:00. The asterisk in the third and fourth fields means every day of the month and every month. The final value, 1, commonly means Monday.

• 15 — minute 15
• 8 — hour 8
• * — every day of the month
• * — every month
• 1 — Monday

Together, the expression runs at 08:15 every Monday.

The Asterisk (*)

The asterisk is one of the most important cron characters. It means that every valid value for that field is allowed.

* * * * *

In the traditional five-field format, this expression matches every minute. Each asterisk represents all possible values for its corresponding field.

Specific Values

A field can contain a specific value when a task should run at one particular minute, hour, day, month, or weekday.

0 9 * * *

This runs at 09:00 every day. The minute is fixed at 0 and the hour is fixed at 9, while the remaining fields allow every valid value.

Cron Ranges

A range specifies a continuous set of values using a hyphen. For example, 9-17 in the hour field represents every hour from 09:00 through 17:00.

0 9-17 * * *

This expression runs at the start of every hour from 09:00 through 17:00 each day.

Cron Lists

A comma-separated list lets you specify several individual values without including everything between them.

0 9,13,17 * * *

This runs at 09:00, 13:00, and 17:00 every day.

Lists can also be combined with ranges when supported by the cron implementation.

Step Values

A slash introduces a step value. It is useful when a task should run at regular intervals rather than at every possible value.

*/15 * * * *

This runs every 15 minutes: at minutes 0, 15, 30, and 45 of each hour.

0 */2 * * *

This runs at minute 0 every two hours.

Combining Cron Operators

Cron expressions become more useful when operators are combined. A schedule can use specific values, ranges, lists, and steps in different fields.

*/10 9-17 * * 1-5

This represents every 10 minutes during the hours from 09:00 through 17:00 on weekdays, using the traditional five-field interpretation.

Common Cron Expressions

Understanding Day of Month and Day of Week

The interaction between the day-of-month and day-of-week fields is one of the most commonly misunderstood parts of traditional cron. When both fields are restricted rather than using an asterisk, traditional cron implementations generally treat them with OR semantics rather than requiring both conditions to match.

0 9 1 * 1

Depending on the cron implementation, this can run at 09:00 when the day of the month is the first or when the day of the week is Monday. This behavior differs from the intuitive interpretation that both conditions must be true.

Month and Weekday Names

Many cron implementations allow names instead of numeric values for months and weekdays. For example, JAN can represent January and MON can represent Monday.

0 9 * JAN MON

The exact accepted names and syntax depend on the implementation. Numeric values are often easier to transfer between systems because they avoid differences in supported names.

Cron Special Characters

Traditional cron syntax is deliberately compact. These few operators are enough to describe a large number of recurring schedules.

Cron Expressions vs Human Time Intervals

Cron is based on calendar fields rather than arbitrary elapsed-time intervals. This distinction matters when designing schedules.

For example, */30 in the minute field means minute 0 and 30 of every hour. It does not mean that the command will necessarily run exactly 30 minutes after the previous execution if a previous run is delayed or the scheduler is unavailable.

Cron is therefore best understood as a calendar-based matching system rather than a precise timer mechanism.

Cron Scheduling and Time Zones

Time zones can affect when a cron task actually runs. Traditional cron daemons commonly use the system's configured time zone unless their configuration or the scheduler provides another mechanism.

Daylight saving time can create unusual situations. A local time may occur twice when clocks move backward or may not occur at all when clocks move forward. Cron implementations can handle these cases differently.

Cron vs Fixed Delays

A cron expression describes calendar conditions. If you need a task to run a certain amount of time after another event, cron may not be the appropriate scheduling mechanism.

• Use cron for recurring calendar-based schedules.
• Use application timers for short-lived in-process intervals.
• Use job queues for distributed background work.
• Use specialized schedulers when workflows require dependencies or retries.

How to Read a Cron Expression

A reliable way to interpret a cron expression is to inspect the fields from left to right and translate each one into plain language.

30 6 * * 1-5

• 30 — at minute 30
• 6 — during hour 6
• * — every day of the month
• * — every month
• 1-5 — Monday through Friday

The complete schedule is therefore 06:30 on weekdays.

Testing Cron Expressions

A cron expression should be tested before it is used for an important production task. Small syntax mistakes can produce a schedule that is either too frequent, too infrequent, or completely different from what was intended.

A cron expression parser can help explain each field, while a validator can identify malformed expressions. A next-run calculator is useful for checking the actual upcoming execution times.

Common Cron Mistakes

• Putting fields in the wrong order.
• Confusing day-of-month with day-of-week.
• Assuming */30 means exactly 30 minutes after the previous run.
• Forgetting that different cron implementations may support different extensions.
• Ignoring the server's time zone.
• Using an expression without checking its next execution times.
• Assuming every scheduler uses the traditional five-field format.

Five-Field Cron vs Extended Formats

The traditional Unix cron format uses five scheduling fields, but some systems and tools support additional fields or special expressions. For example, certain schedulers add a seconds field or provide special shortcuts such as @daily or @reboot.

This means that a cron expression copied from one environment should not automatically be assumed to work identically in another. Always identify the scheduler and its supported syntax.

Cron Shortcuts

Some cron implementations provide predefined shortcuts for common schedules. Examples can include @hourly, @daily, @weekly, @monthly, and @reboot.

@daily

Shortcuts can make configuration easier to read, but their availability depends on the cron implementation. Traditional five-field expressions are often more explicit when portability is important.

Best Practices for Writing Cron Expressions

• Write schedules in plain language before converting them into cron syntax.
• Keep expressions as simple as possible.
• Use comments to document non-obvious schedules.
• Check the scheduler's exact cron dialect.
• Verify the next few execution times.
• Consider the system time zone and daylight saving behavior.
• Avoid unnecessarily frequent jobs.
• Make scheduled commands safe to run repeatedly when possible.

Example: Scheduling a Daily Backup

Suppose a server should start a backup every day at 02:30. The schedule can be represented with:

30 2 * * *

The command associated with this schedule would then be executed at 02:30 according to the scheduler's applicable time zone.

Example: Running a Job Every Fifteen Minutes

For a task that should run at regular quarter-hour boundaries, use:

*/15 * * * *

This matches minute 0, 15, 30, and 45 of every hour.

Example: Running a Weekday Task

To run a task at 09:00 from Monday through Friday, a common expression is:

0 9 * * 1-5

The weekday range limits execution to Monday through Friday while the other fields allow any day of the month and month.

Cron Expression Validation

Validation is useful because a syntactically valid-looking expression can still represent the wrong schedule. For example, switching the minute and hour values can produce a completely different execution time without necessarily producing an obvious syntax error.

After validating an expression, checking its next execution time is a useful second step. This confirms that the schedule matches the intended calendar behavior.

Conclusion

Cron syntax provides a compact way to describe recurring calendar-based schedules. The traditional format contains five fields for minutes, hours, days of the month, months, and days of the week. Values can be combined with asterisks, lists, ranges, and step expressions to create simple or sophisticated schedules.

The most important part of working with cron is understanding exactly how each field is interpreted and remembering that cron implementations can differ. For reliable automation, validate expressions, check their next execution times, account for time zones, and document schedules that are not immediately obvious.