Schemalagda inlägg publiceras inte, backuper uteblir och Action Scheduler-jobb fastnar? Så kontrollerar du DISABLE_WP_CRON, sätter upp riktig system-cron och åtgärdar förfallna jobb.

Cron-problem kraschar aldrig en sajt. Schemalagda inlägg fastnar på ”Missat schema”, nyhetsbrev slutar gå ut, backuper uteblir i det tysta och WooCommerce-ordrar blir kvar i fel status – samtidigt som varje sida laddar som vanligt och varje upptidskontroll lyser grönt. När någon väl märker det har det ofta gått flera dagar. Den här guiden handlar om att fånga tystnaden tidigt, och om de vanliga bovarna när du väl har gjort det.

Därför tystnar cron utan att något syns

WP-Cron är ingen riktig schemaläggare. Den körs när någon besöker sajten: varje sidladdning kollar om det finns jobb som ska köras. På en sajt med lite trafik blir jobben försenade; är DISABLE_WP_CRON satt utan en system-cron bakom körs de aldrig. Action Scheduler – kön som WooCommerce och många plugins använder – startas via WP-Cron, så när den ena stannar stannar båda. Inget av det ger ett fel som en besökare någonsin ser.

De tidiga tecknen

Förfallna händelser. I WP Crontrol (Verktyg → Cron Events) betyder händelser med körtider långt bakåt i tiden att cron inte startar.
Förfallna åtgärder. Under Verktyg → Scheduled Actions pekar en växande hög med Past-due åt samma håll; några Failed kan också blockera kön bakom sig.
”Missat schema” på inlägg som borde ha publicerats.
Webbplatshälsa varnar för att loopback-anrop misslyckas – sajten når inte sin egen wp-cron.php.

Alla de här tecknen kräver att någon går in och tittar. Poängen med övervakning är att ingen ska behöva det.

Bevaka utifrån: en heartbeat

Den mest pålitliga signalen är en så kallad dead man’s switch. I stället för att fråga ”har något gått fel?” väntar du dig ett livstecken enligt schema – och får ett larm när det uteblir. En heartbeat-monitor (i Ravnsight en monitortyp i Pro) ger dig en unik adress att pinga. Kör du WP-Cron från en riktig system-cron – den robusta lösningen – låter du samma jobb pinga adressen när det har kört klart:

*/5 * * * * wget -q -O /dev/null "https://dinsajt.se/wp-cron.php?doing_wp_cron" && curl -fsS https://ravnsight.com/hb/DIN-TOKEN >/dev/null

Sätt det förväntade intervallet något längre än cron-schemat. Stannar serverns cron, startar webbhotellet om servern utan den, eller börjar wp-cron.php fallera, så slutar pingarna komma och du får veta det inom några minuter – inte när det visar sig att fredagens backup saknas. Samma knep fungerar för alla jobb som måste köras: ett backupskript, en import, en nattlig synk.

Bevaka inifrån: vad sajten själv rapporterar

En heartbeat visar att schemaläggaren lever, inte att jobben lyckas. Inne i WordPress bevakar Ravnsights Detective-plugin schemaläggaren direkt: det flaggar när WP-Cron är trasigt eller kraftigt försenat, när Action Scheduler har misslyckade eller förfallna åtgärder – med namnen på hookarna bakom, så att du ser vilket plugins jobb som har fastnat – och när schemalagda inlägg har missat sin tid.

När larmet går: de vanliga bovarna

DISABLE_WP_CRON utan system-cron. Någon stängde av den trafikstyrda cronen men lade aldrig till ersättningen. Lägg till ett cron-jobb på servern – eller titta först i webbhotellets panel; många hanterade WordPress-värdar kör ett åt dig.
Blockerade loopback-anrop. En brandvägg, intern DNS eller HTTP-inloggning på en staging-sajt hindrar sajten från att nå sig själv.
En åtgärd som har fastnat. En enda Action Scheduler-åtgärd som misslyckas kan hålla tillbaka resten; läs posterna under Failed först.
En trasig persistent objektcache kan göra schemaläggningen oberäknelig – töm den och se om händelserna börjar köras.

Åtgärda det du hittar och låt sedan signalerna bekräfta det: heartbeat-pingar som kommer i tid och förfallna åtgärder som betas av är beviset på att cron är tillbaka.