Cron expression syntax

Start with the five standard fields

A traditional Unix crontab expression has five whitespace-separated fields, read from left to right: minute, hour, day of month, month, and day of week. Minutes range from 0 through 59, hours from 0 through 23, days of the month from 1 through 31, and months from 1 through 12. Day of week is commonly 0 through 6 for Sunday through Saturday; many Unix implementations also accept 7 for Sunday.

For example, 30 2 * * 1 means minute 30 of hour 2 on a selected Monday, subject to the scheduler's day-field rules. Month and weekday names such as JAN or MON are convenient aliases where the implementation supports them. Whitespace separates fields, so a value that visually contains six pieces is a different dialect or an expression with seconds.

TheDevTab's Cron Parser accepts five-field Unix expressions and also accepts a six-field form with leading seconds. It expands the supported nicknames, explains each field, and calculates the next ten run times in your browser. Nothing is uploaded.

Build schedules with operators

An asterisk means every value in a field, so * * * * * runs every minute. A comma makes a list, as in 0,30 * * * * for two minutes per hour. A hyphen makes an inclusive range, such as 9-17 for hours during a workday. A slash adds a step:*/15 means every 15 values from the field's minimum, while 1-59/2 means every other minute starting at 1.

Operators can be combined within one field, for example 0 9-17 * * MON-FRI. Read each field independently before combining them. A step applies to the values selected by its range or wildcard; it does not mean “after the last time this job ran.” A cron daemon may also prevent overlapping runs or apply a minimum interval, but those are scheduler policies outside the expression.

Unix cron does not universally support Quartz tokens such as ?, L,W, or a year field. If a scheduler documents those tokens, follow its grammar instead of copying an expression from a different system. A parser that accepts an expression only proves that its own dialect can read it.

Remember the day-field OR rule

The most common cron mistake appears when both day of month and day of week are restricted. In traditional Unix cron, the job runs when the month matches and either the day-of-month field matches or the day-of-week field matches. It is not an AND condition when both fields contain specific values. The exception in practice is when one of those fields is a wildcard, where the other field supplies the calendar restriction.

Consider 0 9 1 * MON. It runs at 09:00 on the first day of a month and at 09:00 on Mondays, not only when the first day happens to be Monday. This may create far more runs than a report author intended. To express a strict intersection, use one field for the schedule and put the other condition in a script, or use a scheduler whose documented semantics provide an explicit intersection.

TheDevTab's parser follows this OR behavior when it calculates upcoming runs and describes both calendar clauses. Test an expression around a month boundary and a known weekday rather than trusting a short human translation. The exact command, environment, and missed-run policy still belong to the scheduler that will execute the job.

Use nicknames carefully

Cron nicknames make common schedules readable. @hourly is equivalent to 0 * * * *, @daily and @midnight represent midnight each day, @weekly represents Sunday at midnight, and @monthly runs at midnight on the first day of the month. @yearly and @annually run at midnight on the first day of January.

Nicknames are still interpreted by a particular scheduler. TheDevTab expands the common scheduled nicknames but rejects @reboot because it has no calendar run time to calculate. Do not use a nickname merely because another scheduler accepts it. Confirm that the target crontab supports the same name and gives it the same timezone and missed-run behavior.

Make time zones and next runs explicit

A cron expression usually has no timezone inside its five fields. The daemon may use the host timezone, a service may let each job declare a zone, and a container may inherit a different setting from the machine running it. Daylight saving transitions can create a local time that occurs twice or does not occur at all. Document the intended timezone beside the expression and decide how skipped or duplicated runs should be handled.

TheDevTab calculates next runs in UTC, so its output is a reference for the parsed fields, not a promise about a local scheduler's wall clock. Use Unix Timestamp to inspect an instant or compare seconds and milliseconds when a job log contains epoch values. Then test the schedule through the actual service with a fixed clock or a staging job.

A reliable review records the dialect, field order, timezone, day-field semantics, and behavior after downtime. Those details matter as much as whether the expression looks plausible.