Как это работает
The five fields are minute, hour, day of month, month and day of week, in that order. Each accepts a single value, a list separated by commas, a range with a hyphen, or a step with a slash — so */15 in the minute field means every fifteen minutes. The asterisk is a wildcard meaning every value in the field's range. When both day-of-month and day-of-week are restricted rather than wildcards, standard cron treats them as a union: the job runs if either matches, not both. That single rule is the most common source of a job that fires more often than its author expected.
Non-standard syntax is where portability breaks down. Quartz, the Java scheduler, takes six or seven fields with seconds first and supports L for last, W for the nearest weekday and # for the nth weekday of the month. AWS EventBridge, Kubernetes CronJobs, systemd timers and Vixie cron all differ in small ways: some accept @daily and @reboot macros, some accept a six-field form with seconds, some do not support step values in every field. A parser that accepts everything will tell you an expression is valid when your target scheduler will reject it or, worse, interpret it differently.
The day-of-week numbering is its own trap. Vixie cron and most Unix implementations number Sunday as 0, so 0 and 7 both mean Sunday; Quartz numbers Sunday as 1, making the two systems off by one for every day of the week. A job scheduled with 1 expecting Monday runs on Sunday under the wrong convention, and because both are plausible the error tends to survive review. Where the names SUN, MON, TUE and so on are supported, using them removes the ambiguity entirely and should be preferred.
Daylight saving is the failure that only appears twice a year. In a timezone that shifts forward, an expression scheduled for 02:30 on the transition date refers to a time that does not exist, and implementations disagree on the response: some skip the run, some run at the shifted time, some run twice. In the autumn transition the 01:30 hour occurs twice, and a job scheduled then may run twice or once depending on the implementation. The tool flags any next-run time that falls within an hour of a transition, so the risk is visible while the expression is being written rather than after a quarterly report is missing a day.
Типичные сценарии
- Check what a cron expression found in a server's crontab actually does before changing it.
- Write an expression for a nightly job and confirm the next run times land when you intend.
- Translate a schedule requirement such as every weekday at 9am into a correct expression.
- Diagnose a job that runs twice on one day a year — usually a daylight-saving transition.
- Verify that an expression uses the day-of-week numbering your scheduler expects.
- Confirm the next several run times in a colleague's timezone for a handover or an on-call rotation.
Обновлено: 2026-10-14 — текст статьи показан на английском; интерфейс переведён.