Cron на shared-хостинге не запускается: как проверить задание по шагам
Если cron на shared-хостинге «не работает», проблема обычно не в самом планировщике. Чаще неверно указан путь к PHP, используется относительный путь к скрипту, команда запускается не той версией PHP, задание падает с ошибкой или выполняется, но результат незаметен.
Для владельца сайта лучший способ диагностики — создать простое контролируемое действие и смотреть журнал. Не начинайте с запуска боевого импорта раз в минуту: так можно быстро создать десятки процессов и упереться в лимиты хостинга.
Коротко: что сделать сразу
- Сделайте копию файла, который запускает cron, и его конфигурации.
- В панели хостинга откройте раздел Cron/Планировщик заданий и проверьте расписание и команду.
- Уточните у хостера путь к нужной версии PHP; не угадывайте его.
- Запустите задание временно раз в 5–10 минут и записывайте результат в отдельный лог.
- После успешной проверки верните нормальное расписание и удалите тестовый лог, если он лежит в доступной из веба папке.
Как понять, cron не стартует или скрипт падает
Это две разные проблемы. Если в панели есть история запусков, сначала посмотрите, фиксируется ли попытка. Если попытки есть, планировщик работает, а ошибка находится внутри команды или скрипта. Если запусков нет вообще, проверяйте формат расписания и активность задания.
В cPanel раздел обычно называется Cron Jobs, в ISPmanager — «Планировщик», у других хостеров — «Cron», «Задания по расписанию» или «Планировщик заданий». Поля могут отличаться, но смысл одинаковый: расписание и команда.
Проверьте расписание и часовой пояс
Самая банальная ошибка — ожидать запуск по своему времени, когда сервер работает в другом часовом поясе. В панели хостинга или справке найдите часовой пояс cron. Если сайт ведёт расписание по Москве, а сервер живёт по UTC, задание может «срабатывать не тогда», хотя технически всё исправно.
На время диагностики ставьте интервал 5–10 минут. Запуск каждую минуту создаёт шум и может нагрузить аккаунт, особенно если предыдущая копия скрипта не успевает завершиться.
Путь к PHP и версия интерпретатора
На shared-хостинге сайт может работать на PHP 8.3, а cron по умолчанию запускать системный PHP другой версии. В результате веб-страницы открываются нормально, а задание падает на несовместимом синтаксисе или расширении.
В панели рядом с выбором версии PHP часто есть подсказка для cron или раздел «PHP CLI». Если её нет, спросите поддержку: «Какой полный путь к CLI PHP версии, на которой работает мой домен?». Это безопаснее, чем копировать путь из чужой инструкции.
Если перед правкой cron вы меняете php.ini, config.php или конфигурацию CMS, сначала сохраните копию. Не храните пароли к базе в публичном лог-файле.
Относительные пути — частая причина «cron ничего не делает»
Скрипт, открытый через браузер, обычно стартует из контекста сайта. Cron может запускаться из домашней директории пользователя. Поэтому конструкция вроде include "config.php" или запись в logs/result.txt может обращаться не туда, куда вы ожидаете.
Лучше использовать абсолютные пути внутри приложения или определять их от каталога самого скрипта. Для новичка практический признак такой: вручную через браузер работает, через cron — нет, а в логах «file not found» или «failed to open stream».
Сделайте результат запуска видимым
В настройках задания включите отправку вывода на техническую почту, если панель это поддерживает, либо направляйте диагностический вывод в лог, недоступный из интернета. После одного-двух запусков вы должны увидеть время старта и либо успешное завершение, либо конкретную ошибку.
Если скрипт импортирует товары, отправляет письма или делает резервную копию, не оценивайте успех только по конечному результату. Проверяйте отметку последнего запуска в самой системе и время изменения тестового файла/лога.
Когда cron упирается в лимиты shared-хостинга
Долгий импорт может закончиться по лимиту времени, памяти, CPU или числу процессов. В панели ищите «Использование ресурсов», CloudLinux, CPU/RAM/IO или Entry Processes. Если пик совпадает со временем cron, уменьшайте объём работы за один запуск, добавляйте блокировку от параллельного запуска или обсуждайте тариф.
Не запускайте одновременно несколько одинаковых заданий, если не уверены, что скрипт защищён от повторного запуска. Иначе одна операция может стартовать второй раз до завершения первой.
DNS обычно не виноват, но после переезда есть исключение
Локальный PHP-скрипт cron обычно не зависит от DNS собственного домена. Но если задание обращается к API или к сайту по его доменному имени после переезда, старый DNS-кэш может вести на прежний сервер. Перед изменением DNS сохраните текущие записи.
Распространение новых DNS-записей может занимать до 24–48 часов, потому что провайдеры и резолверы держат кэш до истечения TTL. В этот период часть запросов может попадать на старый адрес.
Как понять, что проблема решена
Задание срабатывает по расписанию несколько раз подряд, в журнале есть корректное время старта и завершения, нужное действие выполняется один раз, а использование CPU/RAM после запуска возвращается к обычному уровню. После теста верните рабочий интервал и убедитесь, что не осталось дублирующих cron-заданий.
Когда лучше остановиться и не экспериментировать
Если cron удаляет файлы, меняет цены, импортирует заказы, отправляет массовые письма или изменяет базу данных, перед тестами сделайте резервную копию базы и конфигурации. Не ставьте частый запуск «для проверки» на боевом сайте.
Не отключайте SSL-проверку в запросах к API и не записывайте токены, пароли MySQL и ключи в общедоступный лог. Если задача уже создаёт дубли или нагружает сайт, сначала отключите её и разберите журнал.
Частые вопросы
Почему cron работает вручную, но не по расписанию?
Чаще отличаются версия PHP, рабочая директория, переменные окружения или права. Сравнивайте журнал CLI-запуска, а не только результат в браузере.
Можно запускать cron каждую минуту?
Технически иногда можно, но на shared-хостинге это часто лишняя нагрузка. Для большинства задач безопаснее реже и с защитой от параллельных запусков.
Нужно ли указывать полный путь к PHP?
На многих хостингах да, особенно если доступно несколько версий. Точный путь лучше взять из панели или у поддержки.
Почему cron запускается не в то время?
Проверьте часовой пояс сервера и расписание. Разница между UTC и локальным временем — очень частая причина.
Читайте также:
Вывод
Исправный cron — это не просто строка расписания. Нужно проверить время, версию PHP, абсолютные пути, журнал и лимиты ресурсов. Если переносили сайт или не уверены в команде запуска, CompMaster может настроить cron и проверить его безопасно на рабочем хостинге.