В проектах на Битриксе я регулярно вижу одну и ту же схему: «пусть это просто повисит в cron». Для одноразовой

В проектах на Битриксе я регулярно вижу одну и ту же схему: «пусть это просто повисит в cron». Для одноразовой мелочи — терпимо. Для регулярной инфраструктурной задачи — уже нет.

У cron есть привычная проблема: он умеет запускать по расписанию, но почти ничего не знает о состоянии системы. Таймеры systemd в этом месте заметно взрослее. Они умеют:
— привязывать запуск к сервису;
— логировать результат через journal;
— контролировать зависимости;
— корректно перезапускать и догонять пропущенные задачи после простоя.

Схема для типового проекта выглядит так: `service` выполняет работу, `timer` задаёт расписание, а systemd следит, чтобы задача не жила отдельно от окружения. Для интеграций, обменов, прогонов очередей и фоновых обработчиков это обычно надёжнее, чем очередной скрипт в `/etc/cron.d`.

Мой вывод простой: если задача важна для бизнеса, я бы не держал её на «голом cron». Лучше один раз собрать нормальный unit-файл, чем потом разбирать тихо потерянные запуска 🛠️