Dlaczego zadanie CRON się nie wykonuje i jak znaleźć przyczynę?
Brak oczekiwanego efektu nie zawsze oznacza, że CRON się nie uruchomił. Zadanie może wystartować i od razu zakończyć się błędem. Sprawdź wpis, harmonogram, polecenie oraz jego wynik — w tej kolejności łatwiej znaleźć przyczynę.
1. Otwórz Zadania Cron
Zaloguj się do panelu DirectAdmin właściwej usługi hostingowej. Na pulpicie, w sekcji Funkcje zaawansowane, kliknij Zadania Cron (1).

2. Sprawdź, czy zadanie istnieje
Na liście odszukaj polecenie odpowiedzialne za daną funkcję. Jeżeli widzisz Brak elementów do wyświetlenia, na tym koncie nie ma żadnego wpisu CRON. Upewnij się, że otworzyłeś właściwą usługę. Samo zapisanie skryptu na serwerze nie tworzy harmonogramu jego uruchamiania.

Jeżeli wpisu brakuje, utwórz go zgodnie z instrukcją dodawania zadania CRON. Gdy zadanie już istnieje, otwórz jego edycję i zachowaj dotychczasową komendę oraz harmonogram przed wprowadzeniem poprawek. Nie twórz drugiego identycznego wpisu do testu.
3. Porównaj harmonogram z czasem serwera
W formularzu porównaj Aktualny czas z polami Minuta, Godzina, Dzień miesiąca, Miesiąc i Dzień tygodnia (3). Zwróć uwagę na czas podany przez serwer, szczególnie jeśli spodziewasz się wykonania o konkretnej godzinie. Przeczytaj również opis Zadanie cron zostanie uruchomione.
Gwiazdka oznacza każdą dopuszczalną wartość danego pola. Na przykład */5 w polu Minuta oznacza co pięć minut, jeśli pozostałe pola tego nie ograniczają. Po zapisaniu poczekaj na najbliższy pasujący termin. Ustawienia kalendarza dobierz do swojej aplikacji — pięć gwiazdek na ilustracji oznacza uruchamianie co minutę, a nie zalecany interwał dla każdej strony.
4. Sprawdź komendę i zachowaj jej wynik
W polu Komenda (4) używaj pełnej ścieżki do programu oraz skryptu. Zweryfikuj istnienie pliku, wielkość liter w nazwie i uprawnienia do odczytu. Ścieżka katalogu w przykładzie jest umowna — wstaw rzeczywiste położenie własnego zadania.
/usr/local/bin/php /home/hostXXXXXX/diagnostyka/zadanie.php >> /home/hostXXXXXX/cron.log 2>&1
Końcówka >> .../ dopisuje do pliku zwykły wynik oraz komunikaty błędów. Wybierz plik poza public_html i katalog, do którego konto może zapisywać. Jeśli komenda kończy się przekierowaniem do /dev/null, na czas diagnozy zastąp je zapisem do logu. Nie dopisuj drugiego, sprzecznego przekierowania.

Nie przyspieszaj bez potrzeby zadania, które wysyła wiadomości, pobiera płatności lub przetwarza zamówienia. Powtórne wykonanie może mieć skutki w aplikacji. Do diagnostyki zachowaj bezpieczny harmonogram i sprawdź jeden oczekiwany przebieg.
5. Odczytaj log i popraw wskazaną przyczynę
Po zaplanowanym terminie otwórz wskazany plik, np. cron.log, w Menedżerze Plików lub pobierz go na komputer. Sprawdź godzinę modyfikacji i ostatnie linie. Przykładowe komunikaty pomogą zawęzić problem:
| Komunikat lub objaw | Co sprawdzić |
| Could not open input file | Ścieżkę do skryptu, nazwę pliku i jego dostępność dla tego konta. |
| Permission denied | Uprawnienia i właściciela skryptu oraz prawo zapisu do katalogu logu. Nie ustawiaj 777 jako uniwersalnej naprawy. |
| command not found | Pełną ścieżkę do programu; CRON może mieć inne środowisko niż sesja interaktywna. |
| Parse error / Fatal error | Błąd kodu, zgodność wersji PHP, wymagane rozszerzenia i zależności aplikacji. |
| Log pusty lub nie powstał | Termin wykonania, poprawność całej komendy, przekierowanie i uprawnienia do zapisu. Pusty log sam nie dowodzi, że zadanie nie wystartowało. |
Wersja PHP uruchamiana z CRON może różnić się od wersji przypisanej do domeny. Jeśli skrypt działa przez przeglądarkę, a nie działa jako zadanie, porównaj wersję PHP CLI, rozszerzenia, zmienne środowiskowe i sposób wyznaczania ścieżek w aplikacji. Sam test adresu strony nie odtwarza środowiska CRON.
6. Sprawdź poprawkę i zakończ dodatkowe logowanie
Po poprawieniu przyczyny obserwuj następny planowy przebieg i sprawdź wynik w aplikacji. Przywróć docelowy harmonogram. Usuń wyłącznie własny, niepotrzebny log diagnostyczny albo ustaw jego rotację — dopisywanie przez >> może z czasem utworzyć duży plik.
Jeśli problem pozostaje, przekaż obsłudze Hostido komendę bez sekretów, harmonogram, godzinę oczekiwanego wykonania i ostatni komunikat błędu. Dzięki temu można sprawdzić konkretny przebieg zamiast szukać na podstawie samego stwierdzenia „CRON nie działa”.
tagi: cron DirectAdmin logi błędów php