Cron отвечает за задачи по расписанию: генерацию sitemap, парсеры, импорты, рассылки, очистку кэша, бэкапы и уведомления.
Если cron не работает, проблема может быть не в самом расписании, а в пути к PHP, правах, рабочей директории, переменных окружения или ошибке внутри скрипта.
Кому нужна такая доработка
Диагностика нужна, если задача вручную запускается, но по расписанию молчит, или если после переноса сервера перестали выполняться автоматические процессы.
- sitemap не обновляется
- парсер не запускается ночью
- импорт товаров не идет
- бэкапы не создаются
- уведомления по расписанию не приходят
Почему задача часто работает нестабильно
Неверный путь к PHP
На сервере может быть несколько версий PHP, а cron запускает не ту или вообще не находит интерпретатор.
Относительные пути в скрипте
Cron запускает скрипт не из папки сайта, поэтому относительные include и файлы могут ломаться.
Нет прав на выполнение
Пользователь cron может не иметь доступа к файлам, логам или папке для результата.
Ошибки не логируются
Если вывод cron уходит в никуда, кажется, что задача просто не запускается.
Что проверить перед началом
Чем точнее исходные данные, тем быстрее можно оценить задачу и не трогать лишние части сайта. Обычно достаточно ссылки, описания ошибки и доступов к той части, где выполняется настройка.
- посмотрите команду cron целиком
- проверьте абсолютный путь к PHP
- запустите команду вручную от того же пользователя
- добавьте лог stdout/stderr
- проверьте права на файлы и папки
Как я это делаю
Я проверяю расписание, команду, пользователя, путь к PHP, рабочую директорию и лог ошибок. После исправления запускаю задачу вручную и проверяю следующий автоматический запуск.
- Проверяю текущую схему: сайт, сервер, форму, сервис, API или cron.
- Фиксирую проблему или нужный сценарий на тестовом примере.
- Делаю точечную настройку, скрипт или интеграцию.
- Проверяю результат как пользователь и оставляю понятное описание выполненной работы.
Что лучше не делать
- не писать cron-команду с относительными путями
- не скрывать ошибки в /dev/null до диагностики
- не запускать тяжелые задачи каждую минуту
- не выполнять cron от root без причины
Сроки
| Починить одну cron-задачу | 30-90 минут |
|---|---|
| Настроить логи и несколько задач | 1-3 часа |
| Сложные импорты и парсеры | индивидуально |
Связанные материалы
- Автоматизировать рутинные задачи на сайте: где скрипт экономит время
- Сделать парсер данных для бизнеса: что можно автоматизировать законно и аккуратно
- Настроить резервное копирование сайта: что должно попадать в бэкап
Вопрос-ответ
Почему вручную работает, а в cron нет?
Потому что отличаются пользователь, рабочая папка, переменные окружения и версия PHP.
Как понять, что cron запускался?
Нужно писать лог запуска и ошибок, а также проверять системные cron-логи.
Можно ли запускать задачу раз в сутки?
Да, это типовой режим для sitemap, отчетов, бэкапов и импортов.
Итог
Cron нужно проверять как серверную команду: путь, пользователь, окружение, права, логи и результат выполнения.
Если нужна такая настройка или ремонт, напишите в Telegram: @rabotator_support. Коротко посмотрю задачу, скажу реальный объем и предложу аккуратный вариант решения.