Når WordPress wp-cron ikke kører, og planlagte opgaver hober sig op

Hvad WP-Cron faktisk er

I WordPress er WP-Cron et planlægningssystem i applikationslaget. Det betyder, at opgaver registreres i WordPress og bliver forsøgt afviklet, når nogen besøger websitet. Ifølge Understanding WP-Cron Scheduling – Plugin Handbook | Developer.WordPress.org er der altså ikke tale om en konstant baggrundsproces på serveren, men om en mekanisme, der trigges af sidevisninger eller et eksternt kald til wp-cron.php.

Det er en vigtig forskel i driftssammenhæng. Et website med lav trafik kan få forsinkede opgaver, fordi der ikke kommer nok requests til at starte cron-kørslerne. Et website med høj trafik kan omvendt få overlap, låsning eller ressourcepres, hvis mange cron-opgaver bliver trigget samtidig, eller hvis en enkelt opgave er tung og blokerer næste kørsel.

WooCommerce bruger desuden ofte Action Scheduler til baggrundsarbejde som e-mails, webhook-forsøg, abonnementer og databehandling. Når WP-Cron ikke kører stabilt, vokser køen af planlagte handlinger typisk hurtigt. WooCommerce beskriver dette i Scheduled actions Documentation – WooCommerce.

Typiske symptomer på at wp-cron ikke bliver afviklet

Planlagte indlæg bliver ikke publiceret til tiden
Ordrebekræftelser, lageropdateringer eller abonnementsfornyelser bliver forsinket
Backup-plugins, cache-rydning eller importjobs starter ikke
Køen i WooCommerce Scheduled Actions vokser med mange forfaldne opgaver
wp-admin føles langsom, fordi plugins forsøger at indhente gamle jobs
PHP error log viser timeout, memory exhaustion eller loopback-relaterede fejl

Konsekvensen er ikke kun funktionelle fejl. Ophobede baggrundsopgaver kan også blive et drifts- og sikkerhedsproblem. Når jobs ligger længe i kø, kan plugins forsøge aggressivt at genstarte dem. Det kan øge CPU-forbrug, databaseaktivitet og svartider. På webshops kan det påvirke checkout, e-mails og synkroniseringer med eksterne systemer.

De mest almindelige årsager

1. Ingen eller ustabil trafik

Den klassiske årsag er simpel: hvis ingen besøger sitet, bliver wp-cron.php ikke trigget ofte nok. Det rammer især mindre websites, intranet, stagingmiljøer og nye shops uden stabil trafik.

2. DISABLE_WP_CRON er slået til uden erstatning

Mange deaktiverer den indbyggede trigger med konstanten DISABLE_WP_CRON for at undgå, at cron kører på almindelige sidevisninger. Det kan være en fornuftig driftsbeslutning, men kun hvis der samtidig er oprettet en rigtig serverbaseret cron, der kalder wp-cron.php regelmæssigt. Uden den er al planlagt afvikling i praksis stoppet.

3. Loopback-requests bliver blokeret

WordPress forsøger ofte at kalde sit eget wp-cron-endpoint via HTTP. Hvis serveren ikke må lave loopback-requests til sig selv, eller hvis DNS, reverse proxy, basic auth, firewall eller Cloudflare-regler blokerer kaldet, kan opgaverne ikke starte korrekt. Det ses ofte i hostingmiljøer med stram netværksisolering eller særlige sikkerhedsregler.

4. Caching, WAF eller botbeskyttelse griber ind

Sikkerhedslag som WAF, rate limiting eller botbeskyttelse kan være nyttige, men de må ikke utilsigtet blokere legitime kald til wp-cron.php. Hvis Cloudflare eller en serverfirewall klassificerer disse requests som uønsket automatisering, kan resultatet blive forsinkede jobs. Det kræver som regel præcise undtagelser frem for at svække sikkerheden generelt. Se også Get started with Bot Fight Mode · Cloudflare bot solutions docs for den overordnede funktion af Cloudflares botbeskyttelse.

5. Tunge eller fejlende cron-opgaver

Problemet er ikke altid selve triggeren. Hvis et plugin planlægger en opgave, der bruger for lang tid, løber tør for hukommelse eller fejler i databasekald, kan cron-køen stoppe eller blive markant forsinket. Det gælder især importjobs, billedbehandling, backup, eksterne API-kald og masseopdateringer i WooCommerce.

Systematisk fejlfinding

Start med at bekræfte symptomet

Kontrollér først, om der faktisk ligger forfaldne opgaver. I WooCommerce kan Scheduled Actions give et hurtigt overblik over, om køen vokser, hvilke hooks der fejler, og om opgaver står som pending, failed eller in-progress. På et almindeligt WordPress-site kan et driftsplugin eller WP-CLI give tilsvarende indsigt.

Kontrollér wp-config.php

Se efter, om der er sat DISABLE_WP_CRON til true. Hvis den er aktiveret, skal du verificere, at serverens opgavestyring rent faktisk kalder wp-cron.php. Se også efter miljøspecifikke konstanter, der ændrer URL-adfærd, SSL eller multisite-routing.

define('DISABLE_WP_CRON', true);

Test om wp-cron.php kan nås

Kald endpointet direkte i browser eller med kommandolinje fra serveren. Du leder ikke efter HTML-output, men efter om requestet gennemføres uden 403, 404, 5xx eller timeout. Hvis kaldet fejler internt fra serveren, peger det mod loopback-, DNS-, proxy- eller firewall-problemer.

curl -I https://example.dk/wp-cron.php?doing_wp_cron

Gennemgå PHP error log og webserver-logs

PHP error log er ofte den hurtigste vej til årsagen. Kig efter memory_limit-fejl, max_execution_time, fatale plugin-fejl, databasefejl og problemer med HTTP-requests. Kombinér dette med access- og error-logs fra Apache eller Nginx for at se statuskoder, svartider og eventuelle blokeringer på wp-cron.php.

Hvis du arbejder systematisk med logs og performance, hænger cron-fejl ofte sammen med bredere driftsproblemer. Relaterede mønstre er beskrevet i WordPress performance i praksis: sådan gør du hjemmesiden hurtigere og mere stabil og Sådan gør du en langsom WooCommerce-webshop hurtigere.

Undersøg om en sikkerhedskomponent blokerer

Hvis du bruger Cloudflare, hosting-firewall, ModSecurity eller et WordPress-sikkerhedsplugin, bør du kontrollere hændelseslogge for blokeringer mod wp-cron.php eller interne POST-requests. Den sikre løsning er normalt en snæver undtagelse for den nødvendige funktion, ikke en bred deaktivering af WAF eller botbeskyttelse.

Kontrollér om køen skyldes et enkelt plugin

Når mange jobs hober sig op, er det ofte fordi ét plugin opretter en stor mængde handlinger eller fejler gentagne gange. Sortér i køen efter hook-navn, plugin-funktion eller gentagne fejlmønstre. På WooCommerce-sites kan betalingsgateways, e-mailplugins, feed-synkroniseringer og lagerintegrationer være hyppige årsager.

Den robuste løsning: brug system-cron

WordPress anbefaler selv at koble WP-Cron til serverens egen scheduler, når drift og forudsigelighed er vigtige. Se Hooking WP-Cron Into the System Task Scheduler – Plugin Handbook | Developer.WordPress.org. Det giver en mere stabil afvikling, fordi cron ikke længere er afhængig af brugertrafik.

Den normale model er at deaktivere den indbyggede trigger og derefter lade serveren kalde wp-cron.php med faste intervaller, ofte hvert 5. minut. Intervallet afhænger af workload. På travle shops kan 1 minut være relevant, men hyppigere kørsel giver kun mening, hvis opgaverne reelt kræver det, og miljøet kan bære belastningen.

# wp-config.php
define('DISABLE_WP_CRON', true);

*/5 * * * * /usr/bin/curl -fsS https://example.dk/wp-cron.php?doing_wp_cron >/dev/null 2>&1

I nogle miljøer er det bedre at bruge WP-CLI frem for HTTP-kald, fordi du undgår visse proxy- og firewallproblemer. Implementeringen afhænger dog af hostingmiljø, filstier og brugerrettigheder og bør testes i staging først.

Sikker og praktisk drift omkring wp-cron

Tag backup før ændringer i cron-strategi, plugins eller serverkonfiguration
Test ændringer i staging, især på WooCommerce-sites med ordreflow og integrationer
Overvåg kølængde, svartider og fejl efter ændringer
Lad ikke sikkerhedsregler blokere wp-cron, men lav målrettede undtagelser
Reducer tunge baggrundsjob ved at optimere import, billedbehandling og eksterne API-kald
Hold WordPress, temaer, plugins og PHP opdateret for at undgå fejl i planlagte opgaver

En del cron-problemer bliver forværret af svag grundkonfiguration. Hvis PHP-version, hukommelsesgrænser, filrettigheder, DNS eller reverse proxy er ustabile, vil baggrundsjob ofte være blandt de første steder, hvor symptomerne viser sig. Derfor bør wp-cron ses som en del af den samlede driftsarkitektur og ikke kun som et WordPress-problem.

For en bredere tilgang til angrebsflade, adgangskontrol, logning og sikre ændringsprocedurer kan det være relevant at kombinere cron-fejlfinding med principperne i WordPress hardening i praksis: sådan reducerer du angrebsfladen på driftkritiske websites og webshops og Praktisk guide til WordPress sikkerhed.

Hvornår problemet er performance snarere end scheduling

Hvis cron bliver trigget korrekt, men opgaverne stadig ikke bliver færdige, er problemet ofte performance eller applikationslogik. Tegnene er lange svartider på wp-cron.php, database-locks, CPU-spidser, stor PHP-memory usage eller køer, der vokser hurtigere, end de kan afvikles. Her hjælper det ikke kun at ændre intervallet. Du skal identificere de dyreste jobs og enten optimere, opdele eller flytte dem.

På større WooCommerce-installationer kan baggrundsopgaver også blive påvirket af tunge produktfiltre, store metadata-tabeller og andre databaseflaskehalse. Hvis cron-opgaver berører produktdata, lager eller prisberegning, kan relaterede performanceproblemer være medvirkende årsag.

Konklusion

Når wp-cron ikke kører, er symptomet ofte en voksende bunke planlagte opgaver, men den reelle årsag kan ligge flere steder: manglende trafik, forkert konfiguration, blokerede loopback-kald, sikkerhedsregler eller tunge plugin-jobs. Den mest stabile løsning i drift er normalt at bruge serverens egen cron i stedet for sidevisninger som trigger. Samtidig bør du kontrollere logs, køer, sikkerhedslag og ressourceforbrug, så du ikke blot flytter problemet. En systematisk tilgang giver både mere stabil drift og mindre risiko for følgefejl i WordPress og WooCommerce.