Cron na hostingu: co da się automatyzować, a gdzie lepszy jest zewnętrzny scheduler

Cron to prosty mechanizm, który uruchamia zadania o ustalonych porach — co godzinę, raz dziennie, co poniedziałek rano. Zamiast pamiętać, że o północy trzeba coś odpalić, ustawiasz zadanie raz, a serwer robi to za Ciebie. Na hostingu współdzielonym cron znajdziesz w panelu jako „zadania cron” i to jedno z tych narzędzi, które potrafią zdjąć z głowy sporo powtarzalnej roboty.

Cron nie jest jednak uniwersalny. Sprawdza się do prostej automatyzacji na Twoim koncie, ale ma granice — zarówno techniczne, jak i wynikające z limitów hostingu. Warto wiedzieć, co spokojnie na nim postawić, a kiedy lepszy jest zewnętrzny scheduler.

Co można automatyzować cronem

Cron świetnie nadaje się do powtarzalnych zadań związanych z samą stroną, które mają się dziać regularnie i bez Twojego udziału:

• Kopie zapasowe. Nocny skrypt robiący kopię plików i bazy to klasyka. Cron pilnuje, żeby backup powstawał codziennie, a nie tylko wtedy, gdy sobie przypomnisz. Jak robić to sensownie, opisuje tekst jak ustawić kopie zapasowe strony, żeby naprawdę działały.
• Zadania cykliczne CMS-a. Wiele systemów, w tym WordPress, ma wewnętrzne zadania: publikowanie zaplanowanych wpisów, wysyłkę powiadomień, czyszczenie. Na wielu hostingach warto podpiąć je pod prawdziwy cron zamiast polegać na mechanizmie odpalanym przy odwiedzinach strony.
• Porządki w danych. Usuwanie starych logów, czyszczenie plików tymczasowych, kasowanie przeterminowanych rekordów.
• Regularne importy i synchronizacje. Pobranie pliku z danymi, odświeżenie feedu produktów, aktualizacja lokalnej kopii z zewnętrznego źródła.
• Powiadomienia i raporty. Prosty skrypt, który raz dziennie sprawdza stan i wysyła maila z podsumowaniem.

Wspólny mianownik: to zadania, które operują na Twoim koncie i nie muszą ruszać co sekundę. Do takich rzeczy cron jest idealny — jest wbudowany, darmowy i nie wymaga żadnej dodatkowej usługi.

Gdzie cron na hostingu ma granice

Cron na współdzielonym hostingu ma jednak realne ograniczenia, o których lepiej wiedzieć zawczasu:

• Minimalny odstęp. Wiele hostingów nie pozwala uruchamiać zadań częściej niż co kilka albo kilkanaście minut. Do sekundowej częstotliwości cron się nie nadaje.
• Limity zasobów. Zadanie cron liczy się do zużycia Twojego konta. Ciężki skrypt uruchamiany często potrafi uderzyć w limity CPU i procesów. Jak je czytać, tłumaczy tekst jak czytać limity hostingu: CPU, RAM, inode, procesy i transfer.
• Uśpione konto. Jeśli konto zostanie zawieszone albo przekroczysz limity, zadania po prostu się nie wykonają. Cron nie ma własnego „poza serwerem” życia.
• Cichy błąd. Zadanie, które padło, zwykle nie krzyczy. Bez podpiętego powiadomienia albo logu możesz miesiącami myśleć, że backup się robi, choć od dawna leży.
• Jedna maszyna. Cron działa na tym serwerze. Gdy serwer ma problem, zadania nie zadziałają i nie masz o tym pojęcia z zewnątrz.

Ten ostatni punkt jest ważny zwłaszcza dla zadań, które mają pilnować dostępności. Skrypt sprawdzający, czy strona żyje, odpalany na tym samym serwerze co strona, jest bezużyteczny, gdy serwer padnie — bo padnie razem z nim. Do monitoringu z zewnątrz służą osobne narzędzia opisane w tekście monitoring uptime: jak sprawdzać, czy hosting naprawdę działa stabilnie.

Kiedy lepszy jest zewnętrzny scheduler

Zewnętrzny scheduler to usługa, która odpala zadania spoza Twojego serwera — najczęściej wywołując pod ustalony adres URL na stronie albo uruchamiając własny kod. Ma sens, gdy cron na hostingu przestaje wystarczać:

• Zadanie musi działać niezależnie od Twojego serwera. Monitoring dostępności czy alert o awarii nie może mieszkać na maszynie, którą właśnie ma pilnować.
• Potrzebujesz pewności i historii wykonań. Zewnętrzne narzędzia zwykle pokazują, czy zadanie się wykonało, kiedy i czy zwróciło błąd. Cron na hostingu tego zwykle nie daje.
• Zależy Ci na alertach o nieudanym uruchomieniu. Dobry scheduler powiadomi Cię, gdy zadanie nie wystartuje. To zamienia ciche awarie w konkretny sygnał.
• Chcesz odciążyć konto. Wypchnięcie wyzwalacza na zewnątrz zdejmuje część obciążenia z hostingu, choć samą robotę i tak zwykle wykonuje Twój serwer.
• Zadanie spina wiele systemów. Gdy automatyzacja dotyczy różnych usług naraz, wygodniej sterować nią z jednego, niezależnego miejsca.

Częsty i praktyczny wzorzec to połączenie obu: na stronie zostaje adres URL, który wykonuje zadanie, a zewnętrzny scheduler tylko go wywołuje o ustalonej porze i pilnuje, czy się udało. Dostajesz wtedy niezależny wyzwalacz i historię wykonań, a logikę trzymasz u siebie.

Jak wybrać w konkretnym przypadku

Prosta zasada pomaga zdecydować, gdzie postawić dane zadanie:

• Zostaje na cronie hostingu, jeśli operuje na Twoim koncie, wystarczy mu odstęp minutowy, a cicha awaria nie jest katastrofą — jak porządki w plikach czy lekkie zadania CMS-a.
• Wędruje do zewnętrznego schedulera, jeśli musi działać nawet przy padniętym serwerze, wymaga potwierdzenia wykonania albo ma pilnować samego hostingu.

Dobra praktyka niezależnie od wyboru: dopnij do ważnych zadań jakiś sygnał życia. Nawet prosty mail „backup zrobiony” albo wpis w logu sprawia, że dowiesz się o awarii, zanim okaże się, że od miesiąca nic się nie wykonuje. Cichy, niedziałający cron jest gorszy niż jego brak, bo daje fałszywe poczucie, że wszystko jest ogarnięte.