Planlagte opgaver, der bare kører: cron uden wp-cron-fælder

Kort svar: WordPress’ indbyggede wp-cron er ikke et ur – den kører kun, når nogen besøger sitet. På stille sites betyder det forsinkede planlagte indlæg, udeblevne mails og abonnementsfornyelser, der trækkes for sent; på travle sites kan en tilfældig sidevisning komme til at bære et tungt job. Løsningen er klassisk og enkel: slå den besøgsdrevne udløser fra med DISABLE_WP_CRON, og lad serverens rigtige cron køre jobkøen fast, typisk hvert femte minut. Så kører planlagte opgaver forudsigeligt og uden at lægge sig i vejen for besøgende.

Fagligt gennemgået: 2. oktober 2026

Næsten al automatisering ender med at læne sig op ad planlagte opgaver: rapporter, synkroniseringer, oprydning, fornyelser. Og de fleste WordPress-sites kører dem på et fundament, der er designet til at virke overalt uden opsætning – ikke til at være præcist.

Denne guide forklarer, hvordan wp-cron faktisk virker, hvornår det bliver et reelt problem, og hvordan du sætter server-cron op, så planlagte opgaver bare kører. Står du med jobs, der allerede er gået i stå, så start i guiden om wp-cron, der ikke virker.

Før du ændrer noget: Tilføj først server-cron, og bekræft at den kører, før du slår wp-cron fra. Slår du kun wp-cron fra, stopper alle planlagte opgaver – også backup, mails og abonnementsfornyelser. Tag en kopi af wp-config.php, før du redigerer den.

Sådan virker wp-cron egentlig

Misforståelsen ligger i navnet. Rigtig cron er serverens urværk, der starter opgaver på klokkeslæt. wp-cron er derimod en tjekliste, WordPress kigger på, når en side indlæses: „er der jobs, hvis tid er overskredet? Så start dem nu.“

Det er elegant, fordi det virker på al slags hosting uden opsætning – og skrøbeligt af præcis samme grund: ingen besøg, ingen jobs. Et indlæg, der er planlagt til klokken 8, udgives først, når den første besøgende kommer forbi – måske 9.14.

Cache-lag forværrer det i stilhed. Besøg, der serveres fra page cache eller et CDN, når slet ikke WordPress, så selv pæne besøgstal kan dække over en jobkø, der kun tømmes sjældent. Omvendt kan et travlt site starte cron-kald ofte, hvilket giver ekstra arbejde på serveren ved tilfældige sidevisninger.

Hvornår det bliver et problem

For en lille blog er forsinkede jobs harmløse. Men listen over tidskritiske opgaver vokser med forretningen:

• Abonnementsfornyelser, der skal trækkes på dagen – se guiden om abonnementsbetalinger i WooCommerce.
• Ordre-webhooks og integrationskøer, som regnskab og fragt venter på.
• Planlagte kampagnepriser – udsalget skal både starte og stoppe til tiden.
• Backup- og vedligeholdelsesjobs.
• Mails i kø, fx nyhedsbreve og påmindelser.

Tommelfingerreglen: hvis et job, der kører tre timer for sent, kan koste penge, tillid eller data, er besøgsdrevet cron det forkerte fundament. De fleste opdager det baglæns – når en kunde spørger, hvorfor fornyelsen ikke blev trukket, eller hvorfor udsalgsprisen hang til klokken ti.

Løsningen: rigtig server-cron

Opsætningen består af to greb. Lav dem i denne rækkefølge, så der aldrig er en periode uden cron.

1. Opret et cron-job på serveren

Brug cron-funktionen i dit hostingkontrolpanel, hvis den findes, eller crontab via SSH. Der er to almindelige måder at køre jobkøen på.

Med WP-CLI, som kører køen direkte i PHP uden om webserveren (stien til WordPress skal tilpasses):

*/5 * * * * cd /sti/til/wordpress && wp cron event run --due-now --quiet

Eller med et HTTP-kald til wp-cron.php, hvis WP-CLI ikke er tilgængelig:

*/5 * * * * wget -q -O /dev/null "https://ditdomaene.dk/wp-cron.php?doing_wp_cron"

WP-CLI-varianten er at foretrække: den rammer ikke webserverens timeouts, og den påvirker ikke page cache eller firewallregler. WordPress’ egen udviklerdokumentation viser HTTP-varianten med et dagligt interval som eksempel; til drift af en webshop er hvert femte minut et mere almindeligt valg, fordi planlagte opgaver ellers kan vente op til et døgn.

2. Slå den besøgsdrevne udløser fra

Når cron-jobbet kører, tilføjer du denne linje i wp-config.php over linjen „That’s all, stop editing!“:

define( 'DISABLE_WP_CRON', true );

Det er hele opsætningen. Jobsene ligger stadig i WordPress’ kø – de bliver bare startet af serveren i stedet for af besøgende. Har du flere sites, så gør det til en del af din standardopsætning.

Multisite

På en WordPress multisite skal køen køres for hvert site i netværket. Med WP-CLI kan du løbe alle sites igennem i ét cron-job:

*/5 * * * * cd /sti/til/wordpress && wp site list --field=url | xargs -I % wp cron event run --due-now --url=% --quiet

Tunge jobs og køer

To situationer kræver et ekstra lag.

Store jobkøer. WooCommerce og mange plugins kører deres opgaver gennem Action Scheduler. I WooCommerce finder du køen under WooCommerce → Status → Planlagte handlinger. Hober ventende handlinger sig op i tusindvis, er det tegn på, at cron-fundamentet halter, eller at et enkelt job fejler igen og igen. Med server-cron på plads tømmes køen støt. Action Scheduler har også sin egen WP-CLI-kommando, wp action-scheduler run, som kan bruges til at tømme en stor kø kontrolleret, fx med --batch-size og --group. Guiden om forfaldne planlagte handlinger går i dybden.

Rigtig tunge opgaver – eksporter, billedbehandling, store synkroniseringer: kør dem som selvstændige WP-CLI-kommandoer i deres eget cron-job på et stille tidspunkt, fx kl. 03, så de hverken slås med hinanden eller med dagens trafik. Giv langkørende jobs en lås, så to kørsler aldrig overlapper. På Linux kan flock klare det:

0 3 * * * cd /sti/til/wordpress && flock -n /tmp/eksport.lock wp min-eksport-kommando

Erstat wp min-eksport-kommando med den kommando, dit plugin eller din integration faktisk stiller til rådighed.

Overvåg, at det kører

Planlagte opgaver fejler stille, så giv dem en stemme. Tjek efter opsætningen med wp cron event list, at tidspunkterne for næste kørsel rykker sig som forventet. wp cron test kan bekræfte, at WordPress’ eget cron-system kan nås.

Sæt derefter én varig kontrol op – fx et lille fast job, der melder „jeg kørte“ til en overvågningstjeneste. Det kaldes en dead man’s switch: alarmen går, når beskeden udebliver, og det er netop sådan, en død cron opdages. Kig også efter symptomer i hverdagen: planlagte indlæg med status „udeblevet“, mails der kommer i bundter, og integrationskøer, der kun rører sig i åbningstiden. Hele disciplinen er samlet i guiden om overvågning af automatiseringer.

Typiske fejl efter omlægningen

• Cron-jobbet kører som forkert bruger. Kører WP-CLI som root eller en anden bruger end webserveren, kan filer blive oprettet med forkerte rettigheder. Brug den bruger, sitet kører som.
• Forkert sti eller PHP-version. Cron har et minimalt miljø. Angiv fuld sti til WordPress, og tjek, at wp og PHP-versionen i cron er de samme, som du bruger på kommandolinjen.
• HTTP-kaldet blokeres. Står sitet bag basic auth, en firewall eller vedligeholdelsestilstand, kan kaldet til wp-cron.php blive afvist. Skift til WP-CLI-varianten.
• Output fylder mailboksen. Uden --quiet eller omdirigering af output kan cron sende en mail ved hver kørsel.

Læs også

• Hub: Automatisering og integrationer
• wp-cron virker ikke: planlagte opgaver kører aldrig
• WP-CLI for begyndere: 10 opgaver, du aldrig mere gør i hånden
• Forfaldne planlagte handlinger i WooCommerce
• Overvåg dine automatiseringer
• WordPress hosting hos Hostious – LiteSpeed, NVMe og dansk support døgnet rundt

Ofte stillede spørgsmål om wp-cron

Er det farligt at slå wp-cron fra?

Nej – DISABLE_WP_CRON slukker kun den besøgsdrevne udløser. Jobsene ligger urørt i køen og køres af server-cron i stedet. Det er kun farligt at slukke uden at have sat server-cron op.

Hvor ofte skal server-cron kalde WordPress?

Hvert femte minut er et almindeligt valg: tæt nok til planlagte indlæg, mails og fornyelser og så let en belastning, at den sjældent kan mærkes. Tidskritiske eller tunge opgaver kan få deres eget job med eget interval.

Hvorfor hober Action Scheduler-handlinger sig op?

Typisk fordi cron-fundamentet er besøgsdrevet på et stille eller hårdt cachet site – eller fordi ét job fejler igen og igen. Sæt server-cron op, og undersøg derefter fejlene i køens log.

Skal jeg bruge WP-CLI eller wget i cron-jobbet?

WP-CLI, hvis den er tilgængelig: den kører køen direkte i PHP uden om webserveren, cache og firewall. wget- eller curl-kaldet til wp-cron.php er en fin reserve, hvis du ikke har SSH eller WP-CLI.