Cron: перевірка виразу й наступні запуски
Пояснює вираз людською мовою і показує наступні пʼять запусків у вашій таймзоні.
Перевіряє вираз до того, як він потрапить на продакшен
Пʼять полів cron легко переставити місцями, а помилка виявиться через тиждень, коли звіт не прийшов. Інструмент перекладає вираз словами й показує конкретні дати наступних запусків: так одразу видно, що «30 3 * * 1» це щопонеділка о 3:30 ночі, а не о пів на четверту щодня. Розрахунок робить та сама бібліотека, що й планувальник Laravel.
PHP сам не парсить cron: це робить система або планувальник фреймворку. У Laravel розклад описується методами замість виразу, і планувальник рахує ті самі моменти через dragonmantank/cron-expression. Тому інструмент поруч показує еквівалент у Laravel Schedule: у код краще писати dailyAt, а не рядок, який ніхто не прочитає.
// Laravel: те саме, але читабельно
Schedule::command('reports:weekly')
->weeklyOn(1, '03:30')
->timezone('Europe/Kyiv')
->withoutOverlapping();
// Symfony Scheduler
#[AsSchedule]
RecurringMessage::cron('30 3 * * 1', new WeeklyReport());
Що питають про цей інструмент
У тій, що вибрана над таблицею. Це важливо, бо системний cron працює в таймзоні сервера, а не застосунку: якщо сервер у UTC, а ви думаєте київським часом, узимку розбіжність дві години, улітку три. Тому в Laravel краще явно ставити timezone у розкладі.
Перехід на літній час: година з 2:00 до 3:00 просто не існує в цю ніч, і завдання в цьому інтервалі пропускається. У жовтні навпаки, година повторюється, і завдання може виконатись двічі. Для щоденних завдань безпечніше ставити час після 4:00.
Cron запустить наступну копію, не питаючи, чи закінчилась попередня, і ви отримаєте два процеси на одних даних. У Laravel це вирішує withoutOverlapping, у чистому PHP блокування через файл або Redis. Це найчастіша причина дублів у продакшені.