Cron-завдання на хостингу: як автоматизувати рутину і звільнити собі руки для важливого

Уявіть: щоранку о 3:00 невидимий помічник створює бекап вашої бази, о 6:00 очищає тимчасові файли, а о 7:00 надсилає вам звіт на пошту. Ви при цьому спите. Або п'єте каву. Або взагалі у відпустці на Балі. Це не фантастика - це cron, один з найпотужніших і водночас найбільш недооцінених інструментів на будь-якому хостингу. Більшість власників сайтів навіть не здогадуються, що він існує. А ті, хто знає - часто бояться його чіпати, бо "а раптом щось зламаю". Сьогодні ми розберемо cron по кісточках: від базового синтаксису до реальних сценаріїв, які заощадять вам години щотижня.

Що таке cron і чому він працює, поки ви відпочиваєте

Cron - це планувальник завдань у Unix/Linux-системах. Думайте про нього як про будильник, але не для вас, а для сервера. Ви кажете: "Щодня о 2:00 запусти цей скрипт" - і сервер слухняно виконує. Без нагадувань, без пропусків, без "ой, забув".

Cron існує з 1975 року. Так, йому майже 50 років, і він досі працює краще, ніж половина модних SaaS-інструментів для автоматизації. Версія, яку ви зустрінете на більшості хостингів - Vixie cron, написана Полом Віксі у 1987 році. Вона стабільна як скеля.

Головна ідея проста: є файл crontab (cron table), де кожен рядок - це одне завдання з розкладом і командою. Сервер перевіряє цей файл щохвилини і запускає те, що потрібно.

Де це корисно на практиці?

• Автоматичні бекапи бази даних і файлів - щоденно або щогодини
• Очищення кешу, тимчасових файлів, старих логів
• Надсилання email-розсилок, звітів, нагадувань
• Оновлення курсів валют, парсинг даних, імпорт товарів
• Перезапуск "зависших" процесів або перевірка доступності сайту

Синтаксис crontab: п'ять зірочок, які керують усім

Ось тут більшість людей відступає. Бачать щось на кшталт */5 * * * * /usr/bin/php /home/user/script.php і закривають вкладку. Даремно. Синтаксис cron - це п'ять полів перед командою. Не більше, не менше.

Зірочка (*) означає "кожне значення". Тож * * * * * - це "щохвилини, кожну годину, кожного дня". Звучить агресивно? Бо так і є. Не ставте так бекапи - сервер подякує.

Кілька реальних прикладів, які ви можете скопіювати прямо зараз:

1. 0 3 * * * /usr/bin/php /home/user/backup.php - бекап щодня о 3:00
2. */15 * * * * /usr/bin/curl -s https://yoursite.com/cron.php - запуск скрипта кожні 15 хвилин
3. 0 9 * * 1 /home/user/weekly-report.sh - звіт щопонеділка о 9:00
4. 0 0 1 * * /usr/bin/find /tmp -type f -mtime +30 -delete - очищення старих тимчасових файлів першого числа кожного місяця
5. 30 */2 * * * /home/user/check-prices.sh - парсинг цін кожні 2 години на 30-й хвилині

Порада: якщо синтаксис лякає, використовуйте онлайн-генератори - crontab.guru перекладає вираз cron людською мовою за секунду.

Як додати cron-завдання: три способи для різних хостингів

Спосіб залежить від того, що вам доступно. На shared-хостингу ви не маєте root-доступу, на VPS - повна свобода. Розберемо кожен варіант.

Спосіб 1: через панель керування (cPanel, DirectAdmin, Plesk)

Найпростіший шлях. У cPanel шукайте розділ "Cron Jobs" або "Заплановані завдання". Там є випадаючі списки для хвилин, годин, днів - жодного ручного вводу зірочок. Вставляєте команду, обираєте розклад, зберігаєте. Все.

Спосіб 2: через SSH-термінал

Підключаєтесь до сервера і набираєте crontab -e. Відкриється текстовий редактор (зазвичай nano або vi). Додаєте рядок з розкладом і командою. Зберігаєте. Перевірити поточні завдання можна командою crontab -l.

Спосіб 3: через файл у /etc/cron.d/ (тільки root)

На VPS або виділеному сервері ви можете створити окремий файл для кожного проєкту. Це зручно, коли завдань багато і ви хочете тримати їх організовано. Формат той самий, але додається поле з ім'ям користувача перед командою.

"Автоматизація - це не про ледачість. Це про те, щоб машини робили те, в чому вони кращі за нас, а ми зосередились на тому, в чому ми кращі за них." - Тім Ферріс, автор "4-годинного робочого тижня"

Помилки, які перетворюють cron з помічника на ворога

Я бачив десятки випадків, коли неправильно налаштований cron-job завалював сервер або просто мовчки не працював місяцями. Ось топ-список граблів, на які наступають навіть досвідчені адміни.

Помилка #1: неправильні шляхи. Cron запускає команди без вашого звичного оточення (environment). Команда php script.php може працювати в терміналі, але не в cron, бо cron не знає, де шукати php. Завжди вказуйте повний шлях: /usr/bin/php /home/user/public_html/script.php.

Помилка #2: забули перенаправити вивід. За замовчуванням cron намагається надіслати весь вивід скрипта на email. Якщо email не налаштований - вивід просто зникає, і ви не дізнаєтесь про помилку. Додавайте > /home/user/logs/cron.log 2>&1 в кінець команди, щоб записувати все у файл.

Помилка #3: накладання завдань. Уявіть: скрипт бекапу виконується 20 хвилин, а ви запускаєте його кожні 10. Два процеси працюють одночасно, потім три, потім сервер лягає. Рішення - використовувати flock (блокувальник файлів): flock -n /tmp/backup.lock /home/user/backup.sh.

Помилка #4: часовий пояс. Ваш сервер може жити у UTC, а ви думаєте, що 9:00 - це київський час. Перевірте командою date на сервері. У cPanel часовий пояс зазвичай можна змінити в налаштуваннях.

Помилка #5: права доступу. Скрипт має бути виконуваним. Якщо це bash-скрипт, виконайте chmod +x script.sh. Для PHP-файлів переконайтесь, що веб-користувач має право їх читати.

Реальні сценарії: від бекапів до антифроду

Теорія - це чудово. Але давайте поговоримо про те, як cron працює у реальних проєктах.

Сценарій: інтернет-магазин на WooCommerce. Власник запускає три cron-завдання. Перше - щогодинний бекап бази MySQL через mysqldump. Друге - щоденне видалення завершених сесій, яке зменшило розмір бази на 40% за місяць. Третє - щотижневий скрипт, який перевіряє ціни конкурентів і надсилає звіт. До автоматизації ці три задачі забирали 5-6 годин на тиждень.

Сценарій: новинний портал. Cron кожні 5 хвилин перевіряє RSS-канали партнерських ЗМІ, парсить нові статті і додає їх у чергу редактора. Окреме завдання о 00:00 генерує XML-сайтмапу для Google. Ще одне - о 4:00 оптимізує зображення, завантажені за попередній день, зменшуючи їх вагу на 30-60%.

Сценарій: SaaS-платформа. Cron перевіряє термін підписок і за 3 дні до закінчення надсилає нагадування. Якщо оплата не надійшла - блокує акаунт через 7 днів. Повністю автоматично. Жодного ручного втручання.

WordPress і wp-cron: окрема історія з підступом

Якщо у вас WordPress, ви вже використовуєте cron. Точніше, wp-cron - вбудований планувальник WordPress. Але є нюанс. Великий нюанс.

Wp-cron - не справжній cron. Він спрацьовує тільки тоді, коли хтось відвідує ваш сайт. Немає відвідувачів о 3:00 ночі - немає бекапу о 3:00 ночі. Для блогу з 50 відвідувачами на день це проблема.

Правильне рішення: вимкнути wp-cron і замінити його справжнім серверним cron-завданням. Два кроки:

1. Додайте у wp-config.php рядок: define('DISABLE_WP_CRON', true);
2. Створіть cron-завдання: */15 * * * * /usr/bin/curl -s https://yoursite.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Тепер WordPress-планувальник працюватиме кожні 15 хвилин, незалежно від трафіку. Бонус - ваш сайт стане швидшим, бо не перевірятиме cron-чергу при кожному завантаженні сторінки. На навантажених сайтах це може дати приріст швидкості до 200-300 мілісекунд на запит.

Моніторинг і дебаг: як переконатись, що все працює

Налаштували cron? Чудово. А як ви дізнаєтесь, що він справді працює? "Ну, завтра перевірю" - найгірша стратегія. Ось що робити замість цього:

• Логування - перенаправляйте вивід у файл і регулярно перевіряйте його
• Зовнішній моніторинг - сервіси на кшталт Cronitor, Healthchecks.io або UptimeRobot можуть відстежувати, чи спрацював ваш cron
• Email-сповіщення - додайте MAILTO=your@email.com на початку crontab
• Системний лог - на більшості серверів cron-події записуються у /var/log/syslog або /var/log/cron

Для дебагу запускайте команду вручну в терміналі з тими самими шляхами, що й у crontab. Якщо вручну працює, а в cron - ні, проблема майже завжди у змінних оточення або правах доступу.

Ви щойно отримали повний набір інструментів для автоматизації будь-яких рутинних завдань на хостингу. Питання не в тому, чи потрібен вам cron. Питання - скільки годин на тиждень ви вже витрачаєте на те, що міг би робити сервер? І головне - що б ви зробили з цим вільним часом?