Kort svar: wp-cron kører kun, når nogen besøger sitet. Bekræft først, at hændelserne faktisk er forsinkede, og test derefter wp-cron.php direkte med en request. Svarer den 200, men opgaverne stadig hænger, er det typisk cache, firewall eller DISABLE_WP_CRON, der blokerer. Den holdbare løsning er en rigtig server-cron hvert 5. minut – så kører opgaverne uanset trafik.
Planlagte indlæg udgives ikke, backup-pluginet sprang natten over, og WooCommerce-mails kommer i klumper. Symptomerne ser forskellige ud, men årsagen er ofte den samme: wp-cron, WordPress’ interne opgavekø, bliver ikke udløst. wp-cron er nemlig ikke en rigtig cron – den kører kun, når en side bliver indlæst. Ingen besøg, ingen opgaver.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplerne i artiklen er genskabte og viser mekanismen på et anonymiseret domæne – de er ikke målinger af hostious.io.
Ved hver sideindlæsning tjekker WordPress, om der ligger forfaldne hændelser i cron-køen. Gør der det, sender WordPress en intern request til wp-cron.php, som afvikler opgaverne i baggrunden. Modellen er robust på et site med jævn trafik, men skrøbelig i tre situationer:
wp-cron.php.Gå til Værktøjer → Webstedstilstand. WordPress advarer selv, hvis en planlagt hændelse er sprunget over. Vil du se selve køen, viser pluginnet WP Crontrol hver hændelse med næste kørselstidspunkt, og med WP-CLI kan du liste de forfaldne direkte:
Notér, hvor længe hændelserne har ventet. Minutter er normalt. Timer betyder, at cron reelt ikke bliver udløst – og så skal du videre til trin 2.
Åbn https://ditdomæne.dk/wp-cron.php i browseren, eller kald den med curl. Siden skal svare med HTTP 200 og en tom side. Får du 403, rammer du en firewall- eller sikkerhedsregel. Får du 401, ligger der adgangskodebeskyttelse på sitet eller mappen. En timeout peger på, at en tung opgave i køen blokerer – typisk et backup- eller import-job, der aldrig bliver færdigt.
Tjek samtidig wp-config.php for linjen define( 'DISABLE_WP_CRON', true );. Den er korrekt, hvis der også er sat en server-cron op. Står den alene – for eksempel som rest fra en tidligere hostingudbyder – er den hele forklaringen: cron er slået fra, uden at noget andet tager over.
| Det du ser | Sandsynlig årsag | Rettelse |
|---|---|---|
| 200, men opgaver hænger stadig | Page cache leverer alt; PHP kører sjældent | Skift til server-cron (trin 4) |
| 403 ved kald af wp-cron.php | Firewall eller sikkerhedsplugin blokerer filen | Undtag wp-cron.php for serverens egen IP |
| 401 ved kald | Adgangskodebeskyttelse på site eller mappe | Undtag filen, eller kald cron med login |
| Timeout ved kald | En fastlåst, tung opgave i køen | Find og fjern hændelsen med WP Crontrol |
| Loopback-fejl i Webstedstilstand | Serveren kan ikke nå sit eget domæne | Se guiden om loopback- og cURL-fejl |
Den holdbare løsning fjerner afhængigheden af trafik helt. Den består af to dele, og rækkefølgen er vigtig:
https://ditdomæne.dk/wp-cron.php?doing_wp_cron hvert 5. minut – eller kører php wp-cron.php direkte fra WordPress-mappen.wp-config.php med define( 'DISABLE_WP_CRON', true ); – lige over linjen “That’s all, stop editing”.Opgaverne er præcis de samme som før; de bliver bare udløst af serveren i stedet for af tilfældige besøg. På alle Hostious-webhoteller kan cron-jobs oprettes direkte i kontrolpanelet, og supporten hjælper gerne med opsætningen, hvis du er i tvivl om stien eller intervallet.
Fejlen “Missed schedule” (“planlagt tidspunkt overskredet”) på et indlæg er ikke en selvstændig fejl – det er wp-cron-problemet set fra redaktionens side. Indlægget skulle udgives på et tidspunkt, hvor ingen cron kørte. Når server-cron er sat op, forsvinder problemet fremadrettet. Indlæg, der allerede er ramt, udgiver du manuelt ved at åbne dem og klikke Udgiv igen.
Tjek også sitets tidszone under Indstillinger → Generelt. Står den på UTC i stedet for København, rammer planlagte indlæg konsekvent to timer forkert – det ligner en cron-fejl, men er en indstilling.
Rettelsen er dokumenteret, når:
Fortryder du, fjerner du blot DISABLE_WP_CRON-linjen og sletter cron-jobbet i panelet – så er den trafikudløste model tilbage. Hænger opgaverne stadig efter skiftet, er det køens indhold og ikke udløseren, der er problemet; find den fastlåste hændelse med WP Crontrol, eller lad Hostious kigge på cron-loggen.
Fordi wp-cron kun kører ved besøg. Var der ingen trafik på udgivelsestidspunktet, får indlægget status “Missed schedule”. En server-cron hvert 5. minut løser det permanent.
Ja – når DISABLE_WP_CRON kombineres med et rigtigt cron-job, der kalder wp-cron.php. Opgaverne er de samme; kun udløseren ændres. Slå den aldrig fra uden at sætte server-cron op først.
Hvert 5. minut er standard og passer til de fleste sites. Webshops med mange ordremails og planlagte handlinger kan gå ned til hvert minut; sjældnere end hvert 15. minut giver mærkbare forsinkelser.