Генератор crontab и конструктор cron-выражений

Что такое cron-выражение?

# Linux crontab entry — runs every 15 minutes
*/15 * * * *  /usr/local/bin/poll-api.sh

# Kubernetes CronJob — weekdays at 9:00 AM UTC
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-report
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "UTC"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: report
              image: report-runner:1.0
          restartPolicy: OnFailure

# GitHub Actions workflow — hourly
on:
  schedule:
    - cron: '0 * * * *'

# AWS EventBridge — first of each month
ScheduleExpression: cron(0 0 1 * ? *)
# (Note: AWS uses the Quartz 6-field form with '?' for day-of-week)

Ключевые возможности

Варианты cron и планировщики

Примеры cron-выражений

*/15 * * * *

0 9 * * 1-5

0 0 1 * *

*/5 9-17 * * 1-5

0 0 1 JAN,APR,JUL,OCT *

0 0 1 * 5

30 2 * * *

@daily

Как составить cron-выражение

1. 1

   Введите или вставьте cron-выражение

   Введите пятипольное cron-выражение в поле выше (например, `*/15 * * * *`). Инструмент разбирает и проверяет ввод на лету — зелёная галочка при корректном вводе, красная ошибка с названием поля при некорректном. Макросы вроде `@daily`, `@hourly` и других тоже принимаются.

2. 2

   Или подкрутите пять отдельных полей

   Не нужно запоминать порядок полей — редактируйте Минуту, Час, День месяца, Месяц или День недели по отдельности через подписанные поля. Полное выражение наверху обновляется автоматически. Используйте `*` для подстановочных знаков, `*/N` для шагов, `a-b` для диапазонов и `1,3,5` для списков.

3. 3

   Выберите пресет для быстрого старта

   Нажмите любой пресет (каждые 15 минут, по будням в 9:00 и т.д.), чтобы загрузить распространённое расписание, а затем подстройте поля под конкретную задачу. Одиннадцать пресетов покрывают паттерны, которые действительно встречаются в продакшене.

4. 4

   Проверьте предпросмотр ближайших запусков

   Посмотрите на пять предстоящих дат и времён запуска — переключайтесь между Local и UTC, чтобы убедиться, что расписание срабатывает в нужный момент. Это самый надёжный способ поймать ловушку POSIX OR между днём месяца и днём недели до того, как она ударит в продакшене.

5. 5

   Скопируйте и вставьте в планировщик

   Нажмите Copy, чтобы скопировать выражение. Вставьте в crontab, systemd-таймер, `cron:` в GitHub Actions, AWS EventBridge, `schedule` в Kubernetes CronJob или в любой совместимый с cron планировщик. Не забудьте проверить часовой пояс целевого планировщика — см. раздел «Лучшие практики» ниже.

Частые ошибки cron

# Задумано: «первая пятница месяца»
0 0 1-7 * 5
# На самом деле: срабатывает 1-7 числа месяца ИЛИ каждую пятницу — оба условия

# Обёртка для настоящей семантики AND
0 0 * * 5  [ $(date +\%d) -le 7 ] && /your-script
# ИЛИ откажитесь от одного условия и примите более широкое расписание

# Написано разработчиком в US East, развёрнуто на сервер с UTC
0 9 * * *  /your-report.sh
# Сработает в 9:00 UTC = 4:00 утра по US East — не то, что задумал разработчик

# Зафиксируйте часовой пояс или пишите явно в UTC
CRON_TZ=America/New_York
0 9 * * *  /your-report.sh

# Задумано: каждые 15 минут
15 * * * *
# На самом деле: раз в час, в минуту 15 (на 4 запуска/час меньше, чем задумано)

# Правильно
*/15 * * * *
# Каждые 15 минут: минуты 0, 15, 30, 45 каждого часа

# Quartz из 6 полей скопирован в Linux crontab
0 0 9 * * 1-5
# Linux читает: минута=0, час=0, день месяца=9, месяц=*, день недели=1-5
# = полночь 9-го числа в месяцах, совпадающих с буднями — хаос

# POSIX из 5 полей, убираем секунды
0 9 * * 1-5
# = по будням в 9:00

# 30 или 31 февраля — никогда не запустится
0 0 30 2 *
0 0 31 2 *
# Парсится, но расписание не сработает никогда

# Используйте паттерн «последний рабочий день февраля» через скрипт
0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /your-script

# Quartz: «последняя пятница месяца» — невалидно в POSIX
0 0 ? * 6L *

# Подход с обёрткой POSIX для последней пятницы
0 0 25-31 * 5  /your-script
# Запуск в пятницу между 25-31 числом любого месяца

Типичные сценарии

Задачи в Linux crontab

Создавайте и проверяйте записи для `/etc/crontab`, `/etc/cron.d/*` или пользовательских файлов `crontab -e`. Используйте предпросмотр ближайших запусков, чтобы убедиться, что расписание попадает в нужное время в часовом поясе сервера, до сохранения.

Расписания Kubernetes CronJob

Сгенерируйте поле `spec.schedule` для Kubernetes CronJob. Kubernetes 1.27+ также поддерживает `spec.timeZone` — используйте переключатель UTC, чтобы спроектировать расписание в UTC, а затем явно задайте `timeZone`, чтобы не зависеть от локального времени рабочего узла.

Запланированные workflow GitHub Actions

Создайте запись `cron:` под `on.schedule`. GitHub Actions всегда работает в UTC — переключите предпросмотр на UTC, чтобы убедиться в расписании. Избегайте интервалов короче 15 минут; планировщик GitHub пропускает короткие интервалы при высокой нагрузке.

Правила AWS EventBridge

Соберите cron-выражение для запланированного правила EventBridge. Учтите: AWS использует шестипольный синтаксис в стиле Quartz с `?` для дня недели — этот инструмент выдаёт пятипольный POSIX, который нужно сконвертировать, добавив секунды (`0`) и заменив `*` в одном из полей дня на `?`.

Запланированные пайплайны GitLab CI

Проверяйте cron-выражение для запланированного CI-пайплайна в GitLab. GitLab использует пятипольный синтаксис POSIX — именно то, что выдаёт этот инструмент, — и UI-выбор даты, но cron-форма даёт более тонкий контроль для нестандартных интервалов.

Cloudflare Workers Cron Triggers

Создайте запись `[triggers.crons]` в `wrangler.toml`. Cloudflare использует пятипольный синтаксис POSIX. Минимальный интервал — одна минута; воркер работает в UTC. Используйте предпросмотр, чтобы убедиться, что триггер срабатывает в ожидаемом окне.

Расписания Node.js node-cron

Создавайте выражения для библиотеки `node-cron`, которая поддерживает как пятипольный POSIX, так и опциональное ведущее поле секунд. Придерживайтесь пяти полей, если конкретно не нужна точность меньше минуты — шестипольные выражения не переносятся в Linux crontab.

Код-ревью и документация

Вставьте cron-выражение из PR или runbook, чтобы мгновенно увидеть, что оно делает — больше не нужно гадать над `30 7 * * 1-5` или доставать справочную карту. Описание на естественном языке также отлично подходит для inline-комментариев и README.

Справочник по синтаксису cron

Порядок полей: М Ч Д М Н

Минута (0-59), Час (0-23), День месяца (1-31), Месяц (1-12), День недели (0-6, при этом 7 тоже = воскресенье). Поле дня недели принимает и числа (0-6), и имена (SUN-SAT, без учёта регистра).

Операторы

`*` = любое значение; `,` = разделитель списка (`1,3,5`); `-` = диапазон (`1-5`); `/` = шаг (`*/15`, `5/10`); имена: JAN-DEC для месяца, SUN-SAT для дня недели (без учёта регистра).

Макросы (псевдонимы)

`@yearly` = `0 0 1 1 *`; `@annually` = `0 0 1 1 *`; `@monthly` = `0 0 1 * *`; `@weekly` = `0 0 * * 0`; `@daily` = `0 0 * * *`; `@midnight` = `0 0 * * *`; `@hourly` = `0 * * * *`. `@reboot` — особый случай (запуск только при загрузке), а не расписание; он отклоняется с пояснительной ошибкой.

Семантика POSIX для дней (правило OR)

Когда ОБА поля — день месяца и день недели — ограничены (ни одно не равно `*`), расписание срабатывает, если совпадает ХОТЯ БЫ ОДНО условие — семантика OR. Когда ограничено только одно, оно и решает. Когда оба равны `*`, подходит любой день. Правило OR работает в vixie cron, BSD cron и большинстве POSIX-реализаций; Quartz использует `?`, чтобы разводить AND и OR.

Шестипольный режим (Quartz-Lite)

Если ввод содержит шесть токенов через пробел, инструмент трактует первый как поле секунд (0-59). Полезно для Quartz, Spring `@Scheduled(cron=...)` и node-cron. НЕ переносимо в Linux crontab и POSIX-планировщики — они воспримут секунды как минуты и сдвинут всё на одну позицию.

Привязка оператора шага

`*/N` привязан к наименьшему значению поля: `*/15` в минуте = `0,15,30,45`, а не «каждые 15 начиная с сейчас». С базой, отличной от подстановочного знака: `5/15` в минуте = `5,20,35,50`. Шаги, не делящие диапазон поля нацело, пропускают значения у границы — это корректно, а не баг.

Границы валидации

минута ∈ [0,59], час ∈ [0,23], день месяца ∈ [1,31], месяц ∈ [1,12], день недели ∈ [0,7]. Значения вне диапазона дают ошибку на уровне поля. День месяца НЕ сверяется с месяцем (`0 0 31 2 *` парсится нормально, но никогда не совпадёт, поскольку в феврале нет 31-го дня — предпросмотр покажет «Нет ближайших запусков»).

Операторы Quartz отклоняются

POSIX cron не поддерживает Quartz-операторы `?` (без конкретного значения), `L` (last), `W` (ближайший рабочий день) и `#` (n-й день недели). Этот инструмент отклоняет их с понятным сообщением «Quartz operators not supported», а не молча трактует как невалидный POSIX. Для расписаний Quartz используйте инструмент с поддержкой Quartz или планировщик Spring.

Ограничение поиска ближайших запусков по годам

Поиск ближайших запусков ведётся максимум на 4 года вперёд; выражения, совпадающие реже (например, паттерны «29 февраля»), покажут «Нет ближайших запусков в течение 4 лет». Это сделано намеренно, чтобы избежать бесконечной итерации для невозможных паттернов.

Лучшие практики для cron-расписаний

Используйте UTC на серверах, конвертируйте при отображении

Настройте серверы на UTC (`/etc/timezone` или `TZ=UTC`) и пишите все cron-выражения в UTC. Конвертируйте в локальное время только при отображении в дашбордах и отчётах. Это исключает целый класс багов с часовыми поясами, особенно болезненных при переходах на летнее время, когда расписания в локальном времени тихо дублируются или пропускают запуск. Используйте переключатель UTC в этом инструменте, чтобы проектировать расписание в UTC с самого начала.

Избегайте ловушки POSIX OR между днём месяца и днём недели

Никогда не ограничивайте одновременно день месяца И день недели, если только не нужна семантика OR. Если нужен «каждый понедельник в январе», пишите `0 0 * 1 1` (день месяца — `*`); если нужно «1-е число каждого месяца», пишите `0 0 1 * *` (день недели — `*`). Правило POSIX OR означает, что `0 0 1 * 1` сработает 1-го числа И каждый понедельник — почти наверняка не то, что задумано. Предпросмотр ближайших запусков поймает это, если проверять перед деплоем.

Явно фиксируйте часовой пояс расписания

Современные планировщики поддерживают фиксацию часового пояса в определении расписания: `CRON_TZ=America/New_York` в начале crontab (vixie cron 3.0+), `spec.timeZone: "America/New_York"` для Kubernetes CronJobs 1.27+, выражение расписания с `ScheduleExpressionTimezone` для AWS EventBridge Scheduler. Фиксируйте часовой пояс явно, а не полагайтесь на настройки сервера — часовые пояса серверов могут меняться без предупреждения во время инфраструктурных миграций.

Распределяйте нагрузку по минутам, а не на :00

Избегайте `0 * * * *` (каждый час в минуту 0) для некритичных задач — на большом масштабе планирование множества заданий ровно на :00 создаёт всплески нагрузки. Подбирайте случайное смещение по минутам (`23 * * * *`, `41 * * * *`) для каждой задачи, чтобы распределить нагрузку. То же касается ежедневных задач: `30 3 * * *` дружелюбнее к вашей базе данных, чем `0 3 * * *`, когда множество заданий сходится к 3:00.

Делайте задания идемпотентными

У cron нет встроенного повтора, нет предотвращения пересечений, нет восстановления пропущенных запусков. Задание должно быть безопасно для повторного выполнения (идемпотентным) и проверять само себя. Вместо «отправить отчёт в 9:00» проектируйте как «отправить сегодняшний отчёт, если ещё не отправлен» — это самовосстанавливается после простоя, случайных двойных расписаний и параллельных запусков. Идемпотентность — это свойство задания, а не планировщика, и это самая важная практика надёжности.

Добавляйте heartbeat для критичных расписаний

Тихий отказ — главное слабое место cron: если расписание не сработало, никто об этом не сообщит. Для критичных задач пусть задание отправляет heartbeat в сервис мониторинга (Healthchecks.io, Cronitor, Dead Man's Snitch) в конце каждого запуска; сервис уведомит, если ожидаемый ping не пришёл. Это ловит и сбой задания, и сбой самого расписания. Бесплатного тарифа хватает большинству личных и малых команд.

Проверяйте через предпросмотр ближайших запусков перед отправкой

Перед деплоем нового cron-расписания посмотрите на пять предстоящих дат и времён в предпросмотре этого инструмента. Переключайтесь между Local и UTC. Убедитесь, что расписание попадает туда, куда задумано — не на пять минут раньше, не в неправильный день, не пропуская выходные, которые важны. Предпросмотр — самый дешёвый возможный тест в продакшене.

Часто задаваемые вопросы