WordPress cron werkt niet wanneer geplande taken te laat, helemaal niet of slechts gedeeltelijk worden uitgevoerd. Dat kan relatief onschuldig beginnen met een gemiste publicatie, maar bij een webshop of website met automatische imports kunnen de gevolgen veel groter zijn.
WordPress gebruikt namelijk geplande taken voor allerlei processen. Denk aan het publiceren van berichten, het verwerken van achtergrondtaken, het uitvoeren van onderhoud en het starten van bepaalde pluginprocessen.
Bij WooCommerce kan dezelfde techniek indirect betrokken zijn bij bestellingen, voorraadprocessen en andere automatische acties. Ook importplugins gebruiken vaak geplande taken om productfeeds of andere gegevens regelmatig bij te werken.
Toch werkt WordPress cron anders dan een traditionele cronjob op een server. Juist dat verschil veroorzaakt veel verwarring.
Daarom is het verstandig eerst te begrijpen hoe WP-Cron werkt, voordat je probeert het probleem op te lossen.
Wat is WP-Cron in WordPress?
WordPress heeft een eigen systeem voor geplande taken. Dat systeem heet WP-Cron.
De naam doet vermoeden dat het om een gewone servercron gaat, maar technisch werkt het anders.
Een traditionele cronjob wordt door het besturingssysteem van de server gestart. Je kunt bijvoorbeeld aangeven dat iedere vijf minuten een bepaald commando moet worden uitgevoerd.
WP-Cron werkt standaard niet op die manier.
WordPress controleert tijdens websiteverkeer of er geplande taken klaarstaan. Wanneer iemand de website bezoekt, kan WordPress zien dat een taak uitgevoerd had moeten worden en deze alsnog starten.
Daarom is WP-Cron eigenlijk een systeem dat echte cronfunctionaliteit simuleert binnen WordPress.
Voor veel eenvoudige websites werkt dat prima. Bij grotere of belangrijkere processen ontstaan echter beperkingen.
Waarom kan WordPress cron te laat worden uitgevoerd?
Stel dat je een bericht plant voor 03:00 uur ’s nachts.
Wanneer niemand rond dat tijdstip de website bezoekt, is er mogelijk geen verzoek dat WP-Cron activeert.
Pas wanneer om 07:20 uur iemand de website opent, merkt WordPress dat er nog een taak klaarstaat.
Het geplande bericht kan dan pas worden verwerkt.
Voor een blog is zo’n vertraging misschien niet ernstig. Voor een voorraadimport of andere bedrijfskritische taak kan dit wel een probleem zijn.
Daarom zie je bij websites met weinig verkeer relatief vaak meldingen waarbij WordPress geplande taken achterlopen.
Het opvallende is dat hetzelfde probleem ook bij zeer drukke websites kan ontstaan. Daar kan WP-Cron juist te vaak worden aangeroepen, waardoor onnodige belasting ontstaat.
WP-Cron werkt niet betekent niet altijd dat cron zelf defect is
Wanneer iemand zegt dat WP-Cron niet werkt, kan dat verschillende dingen betekenen.
Soms wordt de geplande taak helemaal niet gestart.
In andere gevallen start de taak wel, maar loopt het proces tijdens uitvoering vast.
Dat verschil is belangrijk.
Stel dat een productimport iedere nacht om 02:00 uur hoort te starten. In de logs zie je dat het proces om 02:00 uur daadwerkelijk is begonnen, maar na twaalf minuten stopt.
Dan is het probleem niet de planning.
De cronjob heeft zijn werk gedaan door het proces te starten.
Het probleem zit daarna bijvoorbeeld in PHP, geheugen, CPU, de database of de externe feed.
Daarom moet je eerst vaststellen of de taak niet start of wel start maar niet voltooid wordt.
WordPress import stopt halverwege
Een WordPress import stopt regelmatig tijdens grote XML-, CSV- of productimports.
De oorzaak kan heel ergens anders liggen dan bij WP-Cron.
Een import kan bijvoorbeeld duizenden producten moeten verwerken. Voor ieder product moeten mogelijk afbeeldingen worden opgehaald, categorieën worden gekoppeld en eigenschappen in de database worden geschreven.
Dat kost tijd en servercapaciteit.
Wanneer PHP slechts een beperkte uitvoeringstijd toestaat, kan het proces worden afgebroken voordat het klaar is.
Ook onvoldoende geheugen kan problemen geven.
Daarnaast kan een externe leverancier tijdelijk langzaam reageren. De import wacht dan op data of afbeeldingen totdat een timeout wordt bereikt.
Daarom moet je bij een mislukte import altijd naar het volledige proces kijken.
PHP speelt een grote rol bij cronproblemen
WordPress draait grotendeels op PHP.
Dat geldt ook voor veel cronprocessen.
Wanneer een WordPress cronjob start, gelden er bepaalde PHP-instellingen. Afhankelijk van de manier waarop de taak wordt uitgevoerd, kunnen die instellingen zelfs verschillen van de waarden die je op de website zelf ziet.
Dat gebeurt bijvoorbeeld wanneer een servercron via PHP CLI draait.
De command-lineversie van PHP kan een ander configuratiebestand gebruiken dan PHP-FPM of de PHP-versie die via het hostingpaneel voor de website is geselecteerd.
Daardoor kan een website bijvoorbeeld PHP 8.3 gebruiken, terwijl een handmatige cronjob per ongeluk via een oudere PHP-versie wordt gestart.
Dit kan onverwachte fouten veroorzaken.
Bij cronproblemen moet je daarom niet alleen controleren óf PHP draait, maar ook welke PHP-versie de taak daadwerkelijk gebruikt.
WordPress memory limit en cronjobs
Grote achtergrondprocessen hebben soms veel geheugen nodig.
Een eenvoudige geplande taak die één databasewaarde wijzigt gebruikt nauwelijks resources.
Een productimport waarbij duizenden records worden verwerkt is iets anders.
Wanneer het beschikbare geheugen wordt overschreden, kan PHP het proces beëindigen.
Op de website zie je daar niet altijd een duidelijke melding van.
De gebruiker merkt alleen dat de import niet compleet is.
In serverlogs of WordPress-debuglogs kan dan bijvoorbeeld een geheugenfout zichtbaar worden.
Daarom heeft het weinig zin om een cronjob simpelweg vaker te laten draaien wanneer het proces iedere keer tegen dezelfde geheugenlimiet aanloopt.
Eerst moet de echte oorzaak worden opgelost.
Waarom een echte server cron betrouwbaarder kan zijn
Voor websites met belangrijke geplande processen wordt vaak gekozen voor een server cron voor WordPress.
Daarbij is het besturingssysteem verantwoordelijk voor het starten van de taak.
Je kunt bijvoorbeeld instellen dat iedere vijf minuten een WordPress-cronproces wordt uitgevoerd.
Het grote voordeel is dat de taak niet meer afhankelijk is van bezoekers.
Of er nu nul bezoekers of tienduizend bezoekers zijn, de server start de cronjob volgens het ingestelde schema.
Dat maakt deze aanpak voorspelbaarder.
Voor eenvoudige websites is dat misschien niet nodig. Voor webshops, automatische feeds en andere zakelijke processen is een echte servercron vaak logischer.
WP-Cron uitschakelen bij een server cron
Wanneer je een echte servercron gebruikt, is het gebruikelijk om de standaard WP-Cron-trigger van WordPress uit te schakelen.
Anders kunnen beide systemen dezelfde geplande taken proberen te starten.
Dat is niet altijd direct rampzalig, maar het veroorzaakt onnodige belasting en kan bepaalde processen ingewikkelder maken.
De servercron wordt dan de vaste trigger.
WordPress blijft zijn interne lijst met geplande taken gebruiken, maar het starten daarvan gebeurt gecontroleerd vanuit de server.
Hierdoor combineer je het planningssysteem van WordPress met de betrouwbaarheid van een echte cronjob.
Dit is vooral nuttig wanneer timing belangrijk is.
Hoe vaak moet een WordPress cronjob draaien?
Hier bestaat geen universeel antwoord op.
Een veelgebruikte servercron kan bijvoorbeeld iedere vijf minuten draaien.
Maar dat betekent niet dat iedere website exact die frequentie nodig heeft.
Een website die één keer per nacht een back-upproces moet starten heeft geen cron nodig die iedere minuut wordt aangeroepen.
Een webshop met frequente achtergrondtaken kan juist baat hebben bij een korter interval.
De juiste frequentie hangt daarom af van de processen die uitgevoerd moeten worden.
Te weinig uitvoeren kan vertraging veroorzaken. Te vaak uitvoeren kan juist onnodige serverbelasting opleveren.
De beste aanpak is dus niet “zo vaak mogelijk”, maar zo vaak als functioneel nodig is.
Waarom zware cronjobs elkaar kunnen overlappen
Een belangrijk probleem ontstaat wanneer een taak langer duurt dan het interval waarmee deze wordt gestart.
Stel dat je iedere vijf minuten een productimport start.
De import zelf heeft tien minuten nodig.
Na vijf minuten begint de tweede uitvoering terwijl de eerste nog bezig is.
Vijf minuten later komt mogelijk een derde proces erbij.
Daarmee kunnen meerdere zware imports tegelijkertijd CPU, geheugen en databasecapaciteit gebruiken.
De website kan vervolgens traag worden of zelfs foutmeldingen geven.
Bij grote processen moet daarom voorkomen worden dat dezelfde taak onnodig parallel wordt uitgevoerd.
Een goed importsysteem houdt daar rekening mee of gebruikt vergrendeling om dubbele runs te voorkomen.
WP All Import cron en grote productfeeds
WP All Import cron wordt veel gebruikt voor automatische XML- en CSV-imports.
Bij grote productfeeds wordt een import vaak niet in één enorm proces uitgevoerd. De werkzaamheden worden verdeeld over verschillende stappen.
Dat is logisch.
Een feed met tienduizenden producten kan te zwaar zijn om binnen één webrequest volledig te verwerken.
Daarom bestaat er vaak een mechanisme waarbij eerst gecontroleerd wordt of een import moet beginnen en vervolgens in kleinere delen producten worden verwerkt.
Wanneer zo’n import stopt, moet je dus bepalen welk onderdeel faalt.
Wordt de import niet geactiveerd? Dan ligt het probleem mogelijk bij de trigger.
Begint hij wel, maar worden slechts enkele producten verwerkt? Dan moet je naar het verwerkingsproces kijken.
Die twee situaties vragen om een andere oplossing.
Externe feeds kunnen het cronprobleem veroorzaken
Bij automatische imports is WordPress maar één kant van het proces.
De externe leverancier of feedserver is eveneens afhankelijk.
Stel dat WordPress om 04:00 uur een XML-feed probeert te downloaden.
De externe server reageert op dat moment met een 403-fout.
WordPress kan de cronjob perfect uitvoeren, maar de import ontvangt geen bruikbare gegevens.
Hetzelfde kan gebeuren bij een timeout of ongeldig XML-bestand.
Daarom moet een goede diagnose ook de externe bron controleren.
Kun je het bestand handmatig bereiken? Is authenticatie vereist? Is de feed volledig? Hoe groot is het bestand?
Zonder die controles wordt een extern probleem soms ten onrechte als WordPress-cronfout behandeld.
WooCommerce cron werkt anders dan veel mensen denken
Bij WooCommerce cron komen meerdere systemen samen.
WooCommerce gebruikt geplande taken voor verschillende achtergrondprocessen.
Daarnaast gebruikt WooCommerce en veel plugins een systeem genaamd Action Scheduler.
Action Scheduler is ontwikkeld om grote hoeveelheden achtergrondtaken betrouwbaarder te verwerken dan eenvoudige losse WordPress-events.
Je komt het bijvoorbeeld tegen bij WooCommerce, subscriptions, webhooks en verschillende uitbreidingen.
Daardoor kun je een situatie krijgen waarin WP-Cron technisch functioneert, terwijl honderden Action Scheduler-taken blijven hangen.
Voor de gebruiker lijkt het dan alsof “cron niet werkt”.
Technisch ligt het probleem echter in de wachtrij van achtergrondtaken.
Wat is Action Scheduler?
Action Scheduler is een taakverwerkingssysteem dat binnen WordPress wordt gebruikt.
Plugins kunnen een actie plannen voor een bepaald tijdstip.
Die actie komt vervolgens in een wachtrij terecht.
In WooCommerce kun je vaak zien hoeveel acties een bepaalde status hebben.
Vooral drie statussen zijn interessant: taken die nog wachten, taken die voltooid zijn en taken die mislukt zijn.
Wanneer duizenden taken blijven wachten, is er waarschijnlijk een probleem.
Wanneer steeds dezelfde actie mislukt, geeft dat vaak een aanwijzing naar de plugin of functie die het probleem veroorzaakt.
Action Scheduler is daarmee niet alleen een uitvoersysteem, maar ook een belangrijke bron voor diagnose.
Waarom duizenden geplande acties een website traag kunnen maken
Een enorme achterstand in WordPress geplande taken kan invloed hebben op de prestaties.
Stel dat een plugin door een fout iedere minuut tientallen nieuwe taken toevoegt zonder oude taken goed af te handelen.
Na verloop van tijd kunnen duizenden of zelfs veel meer acties in de database staan.
WordPress en WooCommerce moeten deze tabellen vervolgens blijven verwerken.
Dat kan het dashboard vertragen en extra databasebelasting veroorzaken.
In zo’n situatie helpt het niet om alleen een snellere cronjob in te stellen.
Eerst moet duidelijk worden waarom de wachtrij zo snel groeit.
Anders maak je het systeem misschien alleen sneller in het produceren van nieuwe problemen.
Een mislukte WooCommerce-taak moet je inhoudelijk bekijken
Wanneer een WooCommerce-action faalt, moet je kijken welke functie de taak probeert uit te voeren.
Een fout tijdens het verzenden van een webhook vraagt om een andere oplossing dan een fout tijdens abonnementsverlenging.
Daarom zijn foutmeldingen en logs essentieel.
Kijk bijvoorbeeld of dezelfde actie steeds terugkeert.
Wanneer één specifieke plugin bij vrijwel iedere fout betrokken is, heb je een duidelijke aanwijzing.
Ook PHP-fouten kunnen zichtbaar worden tijdens een actie.
Zo kun je van de algemene melding “WooCommerce cron werkt niet” naar een concrete technische oorzaak gaan.
WordPress cron en websiteverhuizingen
Een hostingmigratie is een moment waarop cronjobs vaak worden vergeten.
De websitebestanden en database worden naar de nieuwe server gekopieerd.
Daarna wordt DNS aangepast en lijkt alles te werken.
Toch kan op de oude server nog een actieve cronjob staan.
Die oude server blijft vervolgens bijvoorbeeld iedere nacht dezelfde productfeed importeren.
Tegelijkertijd draait op de nieuwe server ook een import.
Nu heb je twee systemen die mogelijk dezelfde externe bron verwerken.
Bij bepaalde koppelingen kan dat vervelende gevolgen hebben.
Daarom moet bij iedere migratie worden gecontroleerd welke cronjobs buiten WordPress op serverniveau zijn ingesteld.
Dubbele cronjobs kunnen gegevens dubbel verwerken
Een dubbele cronjob veroorzaakt niet alleen extra belasting.
Sommige processen zijn niet ontworpen om gelijktijdig uitgevoerd te worden.
Stel dat twee processen tegelijk voorraadgegevens bijwerken.
Het ene proces leest voorraad 10, terwijl het andere proces enkele milliseconden later dezelfde waarde leest.
Beide processen voeren vervolgens hun eigen wijziging door.
Afhankelijk van de software kan hierdoor een race condition ontstaan.
Bij simpele taken merk je daar misschien niets van.
Bij bestellingen, voorraad of externe synchronisaties kan het wél belangrijk worden.
Daarom is het bij kritieke processen verstandig om maar één omgeving verantwoordelijk te maken voor de taak.
WordPress cron en server failover
Bij een server failover wordt dit onderwerp nog belangrijker.
Stel dat je een primaire en secundaire server hebt.
Beide servers bevatten dezelfde website en dezelfde servercron.
Zolang de primaire server actief is, wil je waarschijnlijk niet dat de secundaire server ook dezelfde productimports en externe synchronisaties uitvoert.
Anders heb je technisch wel redundantie, maar ook dubbele processen.
Bij een goede failoverarchitectuur moet daarom worden bepaald welke server de geplande taken uitvoert.
Wanneer de primaire server uitvalt, kan die verantwoordelijkheid eventueel naar de secundaire omgeving gaan.
Failover gaat dus niet alleen over websiteverkeer.
Achtergrondprocessen horen eveneens in het ontwerp thuis.
Cronjobs en databasebelasting
Veel WordPress-cronprocessen communiceren intensief met de database.
Denk aan een import die voor ieder product controleert of het product al bestaat.
Bij 50.000 producten kan dat een groot aantal databasequeries veroorzaken.
Wanneer de database slecht geoptimaliseerd is of onvoldoende resources heeft, kan de cronjob steeds langzamer worden.
Hierdoor lijkt het alsof cron niet goed functioneert, terwijl de echte beperking de database is.
In zo’n situatie moet je bijvoorbeeld kijken naar queryprestaties, database-indexen en de beschikbare servercapaciteit.
Caching kan sommige processen verbeteren, maar niet iedere cronjob profiteert daar automatisch van.
Redis lost cronproblemen niet automatisch op
Na ons artikel over Redis is dit een belangrijk onderscheid.
Redis kan terugkerende databasegegevens versnellen.
Dat betekent echter niet dat een WordPress cronjob die verkeerd is geprogrammeerd ineens goed werkt.
Een import die iedere run een bestand van vijf gigabyte downloadt blijft bijvoorbeeld zwaar.
Een proces dat vastloopt door een externe API-timeout blijft afhankelijk van die API.
Redis is daarom een mogelijke optimalisatielaag, geen vervanging voor goede taakverwerking.
Bij cronproblemen moet je altijd eerst vaststellen waar tijd en resources worden gebruikt.
Cron en webserver timeouts
Sommige geplande taken worden via een HTTP-aanvraag gestart.
Daarbij kunnen webserver- of proxytimeouts een rol spelen.
Een proces kan bijvoorbeeld langer duren dan Nginx, Apache of een externe proxy toestaat.
De browser hoeft daar niet bij betrokken te zijn.
Ook een interne HTTP-call kan tegen een limiet aanlopen.
Een servercron via PHP CLI kan in bepaalde situaties robuuster zijn voor langdurige processen, omdat je niet dezelfde HTTP-laag nodig hebt.
Toch moet ook PHP CLI correct worden ingesteld.
Het vervangen van WP-Cron door servercron helpt dus alleen wanneer de volledige uitvoering goed is ingericht.
Hoe logs helpen bij een WordPress cronprobleem
Zonder logging weet je vooral dát iets misgaat.
Met logging kun je vaak zien waar het misgaat.
Bij een import is bijvoorbeeld interessant wanneer de taak begon, hoeveel items zijn verwerkt en op welk moment een fout ontstond.
Bij servercron kun je uitvoer naar een logfile sturen.
Ook WordPress zelf kan foutmeldingen registreren.
WooCommerce en plugins hebben daarnaast soms eigen logbestanden.
Wanneer een taak iedere nacht om exact hetzelfde punt stopt, is dat waardevolle informatie.
Misschien wordt steeds hetzelfde product verwerkt of wordt iedere keer dezelfde externe API aangeroepen.
Logging verandert een vaag probleem in een technisch onderzoek.
Wat als WP-Cron volledig is uitgeschakeld?
Soms staat in wp-config.php ingesteld dat WordPress de standaard WP-Cron-trigger niet mag gebruiken.
Dat is op zichzelf niet verkeerd.
Het wordt vaak bewust gedaan wanneer een servercron actief is.
Het probleem ontstaat wanneer iemand WP-Cron uitschakelt en daarna vergeet een echte cronjob te configureren.
WordPress blijft dan taken plannen, maar er is niets dat deze regelmatig activeert.
Geplande berichten blijven achterlopen en pluginprocessen worden niet uitgevoerd.
Wanneer WordPress cron niet werkt, is dit daarom één van de eerste configuraties die gecontroleerd moet worden.
Waarom een plugin soms de oorzaak is
Plugins registreren hun eigen cron-events.
Wanneer een plugin slecht is ontwikkeld, kan hij bijvoorbeeld steeds nieuwe events toevoegen zonder oude gebeurtenissen op te ruimen.
Ook kan een update ervoor zorgen dat de callback van een geplande taak niet meer bestaat.
WordPress probeert de taak dan wel uit te voeren, maar kan de benodigde functie niet correct vinden.
Daarnaast kunnen plugins onderling conflicteren.
Daarom is het nuttig te controleren welke plugin eigenaar is van een problematisch cron-event.
Je hoeft niet meteen alle plugins uit te schakelen.
Gericht onderzoek voorkomt vaak veel onnodig werk.
Kan een beveiligingsplugin WP-Cron blokkeren?
Ja, dat kan in bepaalde configuraties.
Een firewall of beveiligingsplugin kan interne verzoeken tegenhouden wanneer deze als verdacht worden gezien.
Ook serverfirewalls, Basic Authentication of restricties op wp-cron.php kunnen invloed hebben.
Dit komt vooral voor bij stagingomgevingen of extra streng beveiligde websites.
Wanneer WP-Cron via een HTTP-request wordt aangeroepen, moet die route bereikbaar zijn op de manier waarop WordPress verwacht.
Een servercron die rechtstreeks PHP uitvoert kan in sommige situaties minder afhankelijk zijn van zo’n externe HTTP-route.
Daarom moet je ook beveiligingsregels meenemen wanneer cron niet wordt geactiveerd.
WordPress cron werkt niet door DNS of localhost-problemen
WordPress kan interne verzoeken naar de eigen website uitvoeren.
Wanneer DNS verkeerd staat of de server zijn eigen domeinnaam niet correct kan bereiken, kan dat problemen veroorzaken.
Ook een verkeerde hosts-configuratie of firewallregel kan interne verzoeken blokkeren.
Vanaf je eigen computer werkt de website dan prima.
Op de server zelf kan dezelfde URL echter een fout geven.
Dit soort problemen zijn lastig te herkennen wanneer je alleen vanuit de browser test.
Daarom kan server-side testen nodig zijn om te bepalen of de website zichzelf daadwerkelijk kan bereiken.
Hoe controleer je een WordPress cronjob systematisch?
De beste aanpak is om niet direct instellingen te wijzigen.
Begin met de vraag: welke taak werkt niet?
Controleer vervolgens of die taak daadwerkelijk gepland staat.
Daarna kijk je of hij wordt gestart.
Start hij niet, dan onderzoek je WP-Cron, servercron en triggerproblemen.
Start hij wel, maar stopt hij later, dan kijk je naar PHP, database, externe diensten en logs.
Bij WooCommerce controleer je daarnaast Action Scheduler.
Bij imports kijk je ook naar de externe feed.
Door die volgorde aan te houden voorkom je dat een serverinstelling wordt aangepast terwijl het echte probleem bijvoorbeeld een foutieve XML-feed is.
Wanneer is een echte servercron voor WordPress aan te raden?
Voor een eenvoudige blogsite is standaard WP-Cron vaak voldoende.
De noodzaak wordt groter zodra timing of betrouwbaarheid belangrijk wordt.
Een WooCommerce-webshop met verschillende achtergrondtaken heeft bijvoorbeeld meer belang bij voorspelbare uitvoering.
Hetzelfde geldt voor een website die iedere nacht duizenden producten importeert.
Ook bij websites met weinig verkeer is servercron nuttig, omdat uitvoering dan niet meer afhankelijk is van bezoekers.
Voor bedrijfskritische processen is een echte cron daarom meestal de professionelere oplossing.
Het kost iets meer configuratie, maar geeft ook meer controle.
WordPress cron en monitoring
Een taak één keer correct instellen is niet hetzelfde als zeker weten dat hij maandenlang goed blijft functioneren.
Plugins worden bijgewerkt.
Feeds veranderen.
Servers krijgen nieuwe PHP-versies.
Een externe API kan zijn authenticatie aanpassen.
Daarom is monitoring belangrijk.
Bij belangrijke cronprocessen wil je eigenlijk weten wanneer een run mislukt.
Een productfeed die drie weken niet meer is bijgewerkt kan bijvoorbeeld prijs- en voorraadproblemen veroorzaken zonder dat iemand het direct merkt.
Goede monitoring kijkt daarom niet alleen of de website online is.
Ook belangrijke achtergrondprocessen verdienen controle.
Veelgemaakte fout: alleen controleren of cron draait
Een cronjob kan iedere vijf minuten succesvol worden gestart en toch waardeloos zijn.
Stel dat de cron technisch telkens exitcode 0 geeft, maar het achterliggende importscript verwerkt nul producten omdat de feed leeg is.
Volgens de server draait cron perfect.
Functioneel gebeurt er niets.
Daarom is applicatiemonitoring belangrijker dan alleen controleren of het cronproces bestaat.
Bij een import kun je bijvoorbeeld controleren hoeveel records daadwerkelijk zijn verwerkt.
Bij voorraadupdates kun je kijken naar de laatste succesvolle synchronisatietijd.
Zo meet je het resultaat in plaats van alleen de techniek eromheen.
WordPress cron werkt niet na een PHP-update
Na een PHP-upgrade kunnen cronproblemen ontstaan terwijl de website op het eerste gezicht nog normaal werkt.
Dat komt omdat een specifieke plugin of achtergrondtaak code gebruikt die niet compatibel is met de nieuwe versie.
De homepage roept die functie misschien nooit aan.
De cronjob doet dat wel.
Daardoor verschijnt het probleem alleen tijdens de geplande taak.
Controleer na grote PHP-updates daarom ook geplande imports, WooCommerce-acties en andere achtergrondprocessen.
Een succesvolle homepage is geen volledige compatibiliteitstest.
Server cron WordPress en DirectAdmin of Plesk
Bij een VPS met DirectAdmin of Plesk kun je cronjobs doorgaans op server- of gebruikersniveau instellen.
Het hostingpaneel maakt de configuratie eenvoudiger, maar de technische regels blijven hetzelfde.
Je moet bijvoorbeeld de juiste PHP-binary gebruiken en het correcte pad naar WordPress kennen.
Ook moet de cronjob onder de juiste gebruiker draaien.
Een foutieve gebruiker kan tot permissieproblemen leiden.
Daarnaast kunnen PHP-versies per domein verschillen.
Daarom moet een server cron WordPress altijd aansluiten op de configuratie van de betreffende website.
Het hostingpaneel helpt bij beheer, maar controleert niet automatisch alle inhoudelijke afhankelijkheden van je cronproces.
Wat is beter: WP-Cron of server cron?
Voor kleine websites is WP-Cron eenvoudig en meestal voldoende.
Je hoeft niets op serverniveau in te stellen.
Voor grotere websites biedt servercron meer voorspelbaarheid.
De keuze hangt daarom af van het belang van de taken.
Een website waarop alleen af en toe een gepland blogbericht wordt gepubliceerd hoeft niet dezelfde infrastructuur te hebben als een webshop met dagelijkse voorraadimports.
De fout ontstaat vooral wanneer WP-Cron voor bedrijfskritische automatisering wordt gebruikt zonder rekening te houden met de beperkingen ervan.
Daarom is er niet één winnaar.
De techniek moet aansluiten bij de toepassing.
WordPress cronproblemen laten onderzoeken door Sanum
Wanneer WordPress cron niet werkt, is het belangrijk om niet alleen de planning zelf te controleren.
Sanum kan bij WordPress- en WooCommerce-websites onderzoeken waar een achtergrondproces daadwerkelijk vastloopt.
Daarbij kan worden gekeken naar WP-Cron, servercron, PHP, databasebelasting, WooCommerce Action Scheduler en externe feeds.
Ook automatische XML- en CSV-imports kunnen worden meegenomen.
Bij grote productfeeds is bijvoorbeeld belangrijk of de trigger correct werkt, hoe snel producten worden verwerkt en of serverresources voldoende zijn.
Wanneer een echte servercron geschikter is, kan die onderdeel worden van de hostingconfiguratie.
Het doel is daarbij niet simpelweg “cron aanzetten”, maar ervoor zorgen dat de benodigde processen aantoonbaar en betrouwbaar worden uitgevoerd.
Werken productimports, WooCommerce-processen of andere geplande WordPress-taken niet betrouwbaar? Dan kan Sanum de volledige cronketen onderzoeken en bepalen of het probleem in WordPress, PHP, de server of de externe bron zit.
Veelgestelde vragen over WordPress cron werkt niet
Waarom werkt WP-Cron niet?
WP-Cron kan problemen geven wanneer er weinig websiteverkeer is, wanneer het systeem bewust is uitgeschakeld of wanneer interne verzoeken worden geblokkeerd. Daarnaast kan de taak zelf starten en vervolgens door een PHP-, database- of pluginfout stoppen.
Is WP-Cron hetzelfde als een server cron?
Nee. WP-Cron is het interne planningssysteem van WordPress en wordt standaard geactiveerd via websiteverkeer. Een echte servercron wordt door het besturingssysteem volgens een vast schema gestart.
Is een server cron beter voor WordPress?
Voor belangrijke of tijdkritische processen vaak wel. Een servercron is niet afhankelijk van websitebezoekers en kan daardoor voorspelbaarder worden uitgevoerd.
Waarom stopt mijn WordPress import halverwege?
Een import kan stoppen door onvoldoende geheugen, een timeout, serverbelasting, databaseproblemen of een fout bij de externe feed. Dat betekent niet automatisch dat cron zelf defect is.
Waarom blijft WooCommerce Action Scheduler achterlopen?
Dat kan ontstaan wanneer acties sneller worden toegevoegd dan ze verwerkt worden of wanneer specifieke taken steeds opnieuw mislukken. Controleer de status en foutmeldingen van de achterlopende acties.
Kan WP All Import met een server cron werken?
Ja. Voor grote automatische imports wordt een servercron vaak gebruikt omdat de uitvoering daarmee niet afhankelijk is van websiteverkeer. De exacte configuratie hangt af van de plugin en hostingomgeving.
Kan een cronjob mijn WordPress-website vertragen?
Ja. Zware taken kunnen CPU, RAM en databasecapaciteit gebruiken. Vooral wanneer meerdere cronjobs tegelijk draaien of processen elkaar overlappen kan de website merkbaar trager worden.
Moet ik WP-Cron uitschakelen wanneer ik een servercron gebruik?
Vaak wel. Daarmee voorkom je dat zowel websiteverkeer als de server dezelfde geplande taken proberen te activeren. De exacte configuratie moet wel correct worden uitgevoerd.
Waarom werkt cron na een hostingverhuizing niet meer?
De servercron kan op de oude hosting hebben gestaan en wordt niet automatisch met WordPress-bestanden meegenomen. Ook PHP-paden, gebruikersrechten en serverinstellingen kunnen op de nieuwe omgeving verschillen.
Kan een oude server na een verhuizing nog cronjobs uitvoeren?
Ja. Als de oude hosting actief blijft en de servercron niet wordt uitgeschakeld, kan deze nog steeds processen starten. Daardoor kunnen bijvoorbeeld imports dubbel worden uitgevoerd.
Heeft Redis invloed op WordPress cron?
Redis kan bepaalde databaseverzoeken versnellen, maar repareert geen defecte cronjob. Een foutieve taak, externe timeout of PHP-probleem blijft afzonderlijk onderzocht moeten worden.
Hoe weet ik of een cronjob echt succesvol is?
Controleer niet alleen of het proces gestart wordt. Kijk ook naar het functionele resultaat, zoals het aantal geïmporteerde producten, de laatste succesvolle synchronisatie of de status van WooCommerce-acties.
