Найнебезпечніший збій планувальника - тиша: cron зламався після міграції сервера, і резервні копії не робилися місяць.
Хуки за результатом:
Schedule::command('backup:run')
->dailyAt('3:00')
->onFailure(fn () => Log::critical('Резервна копія не вдалася'))
->pingOnSuccess('https://hc.example.com/ping/backup');
onSuccess() і onFailure() дивляться на код виходу команди - тож вона має повертати ненульовий код при збої.
Пінг «я живий» (dead man's switch): зовнішній сервіс чекає пінг за розкладом і тривожить, якщо його немає. Це ловить і збій команди, і те, що планувальник узагалі не запускався. pingBefore(), pingOnSuccess(), pingOnFailure().
Вивід: sendOutputTo() / appendOutputTo() у файл, emailOutputOnFailure() - листом лише при збої.
Сам планувальник:
- cron-рядок
* * * * * php artisan schedule:runчиschedule:workпід supervisor у контейнері; schedule:listпісля деплою - що й коли виконається;- події
ScheduledTaskFailed,ScheduledTaskFinished- для власного моніторингу; schedule:pauseна час обслуговування - і не забутиschedule:continue.
Pulse показує повільні й невдалі завдання черги, тож завдання, які планувальник лише ставить у чергу, видно і там.