Zaplanowane zadania przestały się wykonywać

Objaw

Nic nie wygląda na zepsute. Strony się ładują, zamówienia wpadają, panel działa. Ale promocja, która miała się skończyć miesiąc temu, wciąż trwa, mail po zakupie nigdy nie doszedł, a integracja synchronizująca stany co godzinę ostatni raz zsynchronizowała się w lipcu.

W WooCommerce → Status → Zaplanowane działania jest zakładka Termin przekroczony i coś w niej jest. Czasem tysiące pozycji.

Często pierwszym sygnałem jest komunikat na górze panelu, dokładnie takimi słowami:

Harmonogram akcji: Znaleziono 848 akcji z przekroczonym terminem. Coś może być nie tak. Przeczytaj dokumentację »

Zmienia się tylko liczba i jej odmiana: „1 akcję”, „3 akcje”, „848 akcji”. W panelu po angielsku ten sam komunikat brzmi Action Scheduler: 848 past-due actions found; something may be wrong. WooCommerce pokazuje go domyślnie wtedy, gdy choć jedno działanie jest spóźnione o ponad dobę.

Ile to kosztuje

WordPress nie ma prawdziwego harmonogramu. Ma WP-Cron, który uruchamia się tylko wtedy, gdy ktoś wejdzie na stronę, a WooCommerce dokłada na to Action Scheduler dla wszystkiego, co musi przetrwać restart. Prawie wszystko, co w sklepie dzieje się później, jedzie na tej kolejce:

• Zaplanowane promocje nigdy się nie kończą. wc_scheduled_sales to zadanie crona. Jeśli się nie wykona, produkt sprzedaje się w cenie promocyjnej bez końca — to jest bezpośrednia przyczyna promocji, która się nie kończy.
• Maile nie wychodzą. Wiadomości po zamówieniu, przypomnienia o porzuconym koszyku, prośby o opinię, powiadomienia o odnowieniu — wszystko w kolejce.
• Synchronizacja stanów i cen stoi. Integracje z ERP, marketplace’ami i feedami kolejkują swoją pracę; katalog po cichu rozjeżdża się z rzeczywistością.
• Subskrypcje nie obciążają karty. W sklepie sprzedającym abonamenty to jest przychód, który po prostu nigdy nie zostaje pobrany.

Ta usterka przeżywa miesiącami dlatego, że nie produkuje błędu w żadnym miejscu, w które człowiek zagląda. Nie ma białego ekranu. Jest sklep, który po cichu przestał robić wszystko, co miał zrobić później.

Jak to sprawdzić samodzielnie

Trzy podejścia, od najtańszego do najpełniejszego.

1. Ekran, który WooCommerce już ma. WooCommerce → Status → Zaplanowane działania, zakładka Termin przekroczony. Kilka pozycji sprzed paru minut na spokojnym sklepie to norma. Setki albo cokolwiek sprzed godzin — nie.

2. Z wiersza poleceń:

wp cron event list --fields=hook,next_run_relative --format=table
wp action-scheduler status

wp cron event list pokazuje zaległe zdarzenia jako now albo z ujemnym czasem względnym. Jeśli zaległe jest wszystko, to nie odpala się sam WP-Cron.

3. Sprawdź, czy WP-Cron nie został wyłączony i nigdy zastąpiony. W wp-config.php:

grep -n "DISABLE_WP_CRON" wp-config.php

define( 'DISABLE_WP_CRON', true ); samo w sobie nie jest błędem — na obciążonym sklepie to jest zalecana konfiguracja. Błędem staje się wtedy, gdy nikt nigdy nie dodał prawdziwego crona systemowego, który miał go zastąpić. Sprawdź, czy zastępstwo istnieje:

crontab -l | grep wp-cron

Jak naprawić

1. Daj witrynie prawdziwy harmonogram. Przez panel hostingu albo wpisem w crontabie co pięć minut:

   */5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

   Potem ustaw DISABLE_WP_CRON na true, żeby wejścia odwiedzających przestały dodatkowo próbować obsługiwać kolejkę.

2. Przepchnij zaległości raz ręcznie, zamiast czekać, aż nadrobi sama:

   wp action-scheduler run --batch-size=50

3. Zajmij się tym, co zaległości zasłaniały. Promocja, która miała skończyć się trzy tygodnie temu, nie naprawi się sama po restarcie kolejki — część zadań miała terminy, które już minęły. Sprawdź ceny, zanim uznasz, że nadrobienie zaległości załatwiło sprawę.

4. Zajrzyj też do działań nieudanych, nie tylko oczekujących. Zadanie, które wywala się przy każdym przebiegu, zajmuje kolejkę, nigdy się nie kończąc.

Kiedy to fałszywy alarm

• Zupełnie nowy sklep, w którym nic jeszcze nie zostało zaplanowane: brak zaległych działań, ale też brak dowodu, że kolejka działa. Merchlint zgłasza to, co widzi, i mówi to wprost, zamiast zgadywać.
• Hosting uruchamia crona poza witryną, w sposób niewidoczny z bazy. Jeśli DISABLE_WP_CRON jest ustawione, kolejka jest pusta, a ostatnie działania zakończyły się niedawno — wszystko gra. Znalezisko powstaje wyłącznie wtedy, gdy działania są faktycznie zaległe.
• Świadomie zatrzymana kolejka na czas migracji albo dużego importu. To jest w porządku — warto ją odblokować, zanim się o tym zapomni.

Jak znajduje to Merchlint

Merchlint odczytuje tabelę action_scheduler_actions, szukając działań wciąż w stanie pending, których zaplanowany czas minął o więcej niż próg, oraz sprawdza stałą DISABLE_WP_CRON i znacznik czasu ostatniego zakończonego działania. Przy znalezisku widać, ile działań jest zaległych, jak stare jest najstarsze i czy DISABLE_WP_CRON jest ustawione — trzy fakty potrzebne, żeby odróżnić „cron jest wyłączony” od „cron działa, ale się topi”.

Pewność: F — fakt z bazy. Zaplanowany czas albo minął, albo nie.

Ta kontrola trafiła do wersji darmowej 20 sierpnia 2026, bo nazywa przyczynę stojącą za całą klasą innych znalezisk — w tym za promocjami, które się nie kończą, i stanami, które się nie aktualizują. Raport wymieniający objawy bez nazwania tej przyczyny wysyła Cię do poprawiania produktów po jednym.