/tool/cron-parser/ работает считает браузер
Вставьте строку расписания — инструмент скажет по-русски, когда задание сработает, и покажет ближайшие запуски сразу в двух колонках: по часам сервера в выбранном поясе и по вашим. Понимает пять полей Unix, шесть-семь полей Quartz и Spring вместе со знаками L, W и решёткой. Строку можно не писать руками — рядом конструктор и полсотни готовых расписаний, а на выходе есть готовые куски для crontab, Kubernetes, GitHub Actions, systemd и AWS EventBridge. Всё считает браузер.
Разбор идёт на вашем устройстве: ни строка, ни команды никуда не отправляются.
Что стоит в каждом поле, во что оно развернулось и сколько значений получилось.
| Поле | Записано | Значения | Сколько |
|---|
Перевод часов
Число в клетке — сколько раз задание сработает в этот день по часам сервера. Пустая клетка означает, что в этот день запуска нет.
| Пн | Вт | Ср | Чт | Пт | Сб | Вс | За неделю |
|---|
Возьмите готовое или соберите своё мышью. Строка сразу уходит в поле наверху и разбирается тем же кодом — придумывать её в голове не нужно.
Чаще раза в час
Раз в час и по часам
Раз в сутки
Раз в неделю
Раз в месяц и реже
—
То же расписание для тех мест, куда его обычно переносят руками. Пересчёт в UTC там, где часовой пояс задать нельзя, уже сделан.
Подставляется в строку crontab, в контейнер Kubernetes, в шаг GitHub Actions и в юнит systemd. На разбор расписания не влияет.
Вставьте файл как есть — с комментариями, переменными и командами. Каждая строка получит фразу по-русски и ближайший запуск, а строки, которые стартуют одновременно, будут помечены.
Строки с решёткой и присвоения вида PATH=… пропускаются. Псевдонимы @daily и им подобные разбираются наравне с обычными.
Пусто
| Стр. | Расписание | Команда | Что значит | Ближайший |
|---|
Сначала поставьте часовой пояс сервера — тот, на котором стоит cron. Всё остальное считается по нему, а ваше местное время идёт рядом второй колонкой: разницу больше не надо держать в голове.
Вставьте строку расписания без команды. Если строку писать не хочется, возьмите готовую из раздела «Конструктор» или соберите по полям переключателями.
Проверьте фразу по-русски и список запусков. Список — главное: он показывает не то, что вы имели в виду, а то, что действительно получилось.
Загляните в разбор по полям: там видно, во что развернулась каждая запись и сколько значений в ней осталось. Ошибка в шаге или диапазоне видна именно там.
Посмотрите карту на месяц. Провал вроде «31-го числа в апреле запуска нет» виден клеткой без числа раньше, чем вы дочитаете предупреждения.
Если в поясе бывает перевод часов, прочитайте отдельный блок: там сказано, какой запуск в этом году пропадёт весной и какой час повторится осенью.
Готовое забирайте кусками: строка crontab, CronJob для Kubernetes, workflow для GitHub Actions (там время уже пересчитано в UTC), таймер systemd и выражение AWS EventBridge. Всё вместе скачивается одним файлом.
Целый crontab вставляется в последний раздел: он разберёт каждую строку и покажет, какие задания стартуют в одну и ту же минуту.
минута час день месяца месяц день недели
Поля соединяются по «и»: сработать должны все сразу. Исключение одно — день месяца и день недели. В обычном cron и в Spring, если задано и то и другое, они соединяются по «или», и задание сработает в любой из этих дней. Quartz так не умеет и требует, чтобы одно из двух полей было знаком вопроса.
Исходные данные — те же, что стоят в полях по умолчанию: их можно пересчитать в уме и убедиться, что инструмент не врёт.
В каждом часе четыре запуска: 60 ÷ 15 = 4.
Часов в диапазоне с 9 до 18 включительно — десять.
В сутки срабатывания: 4 × 10 = 40 запусков.
Будних дней в окне на 12 месяцев около 260: это 52 недели с хвостом, по 5 будних в каждой.
Если вы сидите в Екатеринбурге, во второй колонке те же запуски идут с 11 до 20 часов — на два часа позже, потому что сервер живёт по Москве.
В GitHub Actions это же расписание пришлось бы записать как 6-15 вместо 9-18: там время всегда UTC. Пересчёт лежит готовым в разделе конфигов.
Получается 40 запусков в сутки и порядка 10 400 за год. Фраза по-русски: по будням каждые 15 минут с 9 до 18 часов.
Спросите сам сервер: команда timedatectl покажет строку Time zone, а если её нет — посмотрите, куда указывает /etc/localtime, или выполните date. Полученное имя вида Europe/Moscow впишите в поле: список подсказок собран из тех поясов, которые знает ваш браузер. Если сервер живёт по UTC — а так настроено большинство облачных машин и все контейнеры по умолчанию, — жмите кнопку UTC.
Зависит от направления. Весной час пропадает: расписание, назначенное на исчезнувшее время, в эти сутки не сработает вовсе. Осенью час повторяется, и одно и то же показание часов наступает дважды — обычный cron запускает задание один раз, по первому проходу. Инструмент ищет переходы в выбранном поясе на 12 месяцев вперёд и отдельной строкой пишет, какая дата и какой запуск попадут под каждый случай. В поясах без перевода часов, включая российские, этот блок остаётся пустым — и это верный ответ.
Да, в режимах Quartz и Spring. L — последний день месяца, L-3 — за три дня до него, LW — последний рабочий день, 15W — ближайший рабочий к 15-му числу, 5#3 — третий четверг, 5L — последний четверг. В режиме Unix эти знаки по-прежнему считаются ошибкой, потому что обычный cron их действительно не понимает: переключите диалект вверху панели.
Нумерацией дней недели. В Quartz воскресенье — единица, понедельник — двойка; в Spring и в обычном cron воскресенье — ноль. Одна и та же строка «0 0 9 ? * 2» означает вторник в Spring и понедельник в Quartz. Ещё Quartz требует знак вопроса в одном из двух дневных полей и умеет седьмое поле — год. Если диалект стоит на «Определить», шесть полей читаются как Spring, и об этом говорится отдельной строкой в замечаниях.
Это правило «или». Строка «0 0 13 * 5» означает не «в пятницу тринадцатого», а «тринадцатого числа любого месяца и вдобавок каждую пятницу». Чтобы получить именно совпадение, ограничение по дню недели ставят внутри самой команды, а не в расписании. В Quartz такой строки просто не существует: там одно из полей обязано быть знаком вопроса.
Потому что расписания в GitHub Actions всегда считаются по UTC, задать пояс там нельзя. Инструмент сам сдвигает часы на разницу с выбранным поясом и пишет получившуюся строку в готовый workflow. Разница берётся на сегодняшний день: если в вашем поясе бывает перевод часов, полгода задание будет уходить на час раньше или позже, и это ограничение самого GitHub, а не пересчёта.
Разбираются: @hourly, @daily, @midnight, @weekly, @monthly, @yearly и @annually. Это просто сокращения для частых расписаний, и в замечаниях видно, во что каждое разворачивается. Псевдоним @reboot тоже опознаётся, но предсказать его нельзя — он привязан не к календарю, а к перезагрузке машины.
Ничего. Разбор, поиск запусков, поиск переходов на летнее время и сборка конфигов идут в браузере на вашем устройстве. Вставленный crontab с командами и путями тоже никуда не отправляется. Выражение и выбранный пояс кладутся в адрес страницы после решётки — эту часть адреса браузер серверу не передаёт, зато ссылкой можно поделиться, и коллега увидит тот же разбор.