Cron — планувальник завдань Linux. Він запускає скрипти за розкладом: щохвилини, щодня, щотижня. У cPanel є зручний інтерфейс для керування cron без знання синтаксису.
Створення cron-завдання в cPanel
- Увійдіть у cPanel → Додатково → Завдання Cron
- Виберіть готовий період (щохвилини, щогодини, щодня) або налаштуйте вручну
- У полі Команда вкажіть команду або шлях до скрипта
- Натисніть Додати завдання Cron
Синтаксис cron
# хвилина година день місяць день_тижня команда
# Кожні 5 хвилин:
*/5 * * * * /usr/bin/php /home/user/public_html/cron.php
# Щодня о 3:00
0 3 * * * /usr/bin/php /home/user/public_html/backup.php
# По понеділках о 9:00
0 9 * * 1 /usr/bin/php /home/user/public_html/report.phpПрактичні приклади
WordPress: wp-cron
Вимкніть вбудований WP-Cron (він навантажує сервер при кожному візиті) і замініть реальним:
# У wp-config.php додайте:
define('DISABLE_WP_CRON', true);
# Cron-завдання (кожні 5 хвилин):
*/5 * * * * /usr/bin/php /home/user/public_html/wp-cron.phpЩоденне очищення логів
0 2 * * * find /home/user/public_html/logs -name "*.log" -mtime +30 -deleteРезервна копія MySQL
0 4 * * * /usr/bin/mysqldump -u dbuser -ppassword mydb > /home/user/backups/db-$(date +\%Y\%m\%d).sql💡 Шлях до PHP у cPanel зазвичай
/usr/bin/php або /usr/local/bin/php. Знайдіть точний шлях через cPanel → PHP → Версії PHP.⚠️ Cron не виводить помилки на екран. Щоб отримувати сповіщення про помилки, додайте на початок crontab:
MAILTO=your@email.comМоніторинг через зовнішній сервіс (dead man's switch)
Cron не скаже вам, що завдання перестало запускатися взагалі — наприклад, якщо акаунт тимчасово заблоковано або впав сервер. Для критичних завдань (бекап БД, надсилання звітів) додайте перевірку через сторонній сервіс на кшталт healthchecks.io або cronitor.io: він чекає HTTP-пінг у заданий інтервал і надсилає алерт, якщо пінгу не було.
# У кінець команди додаємо curl-пінг після успішного виконання
0 4 * * * /usr/bin/mysqldump -u dbuser -ppassword mydb > /home/user/backups/db-$(date +\%Y\%m\%d).sql && curl -fsS -m 10 https://hc-ping.com/your-uuid-here- Пінг надсилається лише при успішному завершенні — якщо mysqldump впаде з помилкою,
&&зупинить ланцюжок і пінг не піде - Сервіс надішле лист або повідомлення в Telegram, якщо очікуваний пінг не прийшов вчасно
- Так вирішується головна проблема штатних сповіщень cPanel: вони мовчать, якщо завдання взагалі перестало запускатися
Часті помилки cron і їхні причини
| Повідомлення в лозі або листі | Що означає |
|---|---|
| /bin/sh: 1: php: not found | У команді вказано просто php без повного шляху. Cron виконує команди з мінімальним PATH і не бачить аліаси оболонки користувача |
| Permission denied | Файл скрипта не позначений як виконуваний, або власник завдання не має прав на шлях, вказаний у команді |
| Завдання спрацювало двічі, друга половина команди зникла | Символ % у команді не екранований. Cron сприймає неекранований % як перехід на новий рядок і обрізає все, що після нього |
| Лист про помилку не надходить, хоча вказано MAILTO | Хостинг блокує вихідну пошту з локального MTA або скринька в MAILTO не існує |
| mysqldump: Got error: 1045: Access denied | Пароль у команді дампу застарів після зміни пароля БД у cPanel → MySQL Databases |
Коли cron у cPanel не підходить
- Потрібна черга завдань з повторними спробами і пріоритетами — для цього потрібен постійно працюючий воркер (Supervisor, systemd), а на shared-хостингу такого доступу немає
- Завдання треба запускати частіше разу на хвилину — мінімальний крок стандартного cron становить 60 секунд
- Скрипт іноді виконується довше, ніж інтервал запуску — без lock-файлу сусідні запуски почнуть накладатися один на одного і створювати гонки
- Потрібні системні завдання з правами root (ротація логів сервера, оновлення пакетів ОС) — на акаунті доступний лише crontab самого користувача
- Потрібен ланцюжок із кількох залежних кроків (спершу вивантаження, потім імпорт, потім сповіщення) — cron не вміє чекати завершення одного завдання перед запуском іншого, окрім грубого склеювання через
&&в одному рядку
Перевірка результату виконання
Після додавання завдання не покладайтеся на те, що «раз помилки не видно — все працює». Перевіряйте результат явно, а розбір причин завислих або падаючих завдань зручно звірити зі статтями про діагностику error_log у cPanel та про автоматичне резервне копіювання.
# Список активних завдань поточного користувача
crontab -l
# Переконатися, що бекап справді створився і не порожній
ls -lh /home/user/backups/
# Файл розміром 0 байт майже завжди означає,
# що mysqldump впав з помилкою доступу або не вистачило диска