Ga naar de inhoud 
WordPress cronjobs falen onder belasting wanneer paginaverzoeken de interne planner blokkeren, caches verzoeken onderscheppen of hostinglimieten lange taken begrenzen. Ik laat de oorzaken, gevolgen en concrete oplossingen zien om ervoor te zorgen dat taken zoals updates, back-ups en geplande berichten betrouwbaar worden uitgevoerd.
Centrale punten
Om te beginnen zal ik de belangrijkste aspecten kort en duidelijk samenvatten voordat ik meer in detail ga en specifieke stappen uitleg die ik productief gebruik. Probleemidentificatie en Oorzaken staan hier centraal.
- MechanicaWP-Cron triggert op pagina-aanvragen in plaats van via systeemcron.
- BelastingVeel verkeer en „wordpress cron load“ genereren timeouts.
- CachingVolledige CDN caching stopt de cron uitvoering.
- GrenzenPHP timeouts en resource budgetten annuleren taken.
- remedieServer cron, schone intervallen, logging en tuning.
WP-Cron kort uitgelegd: Pagina-oproep in plaats van systeemservice
Ik begin met de BasisideeWordPress controleert bij elke opgevraagde pagina of de geplande taken klaar zijn en vuurt ze af via een intern HTTP-verzoek naar wp-cron.php. Deze aanpak compenseert het gebrek aan toegang tot echte server crones, maar creëert een afhankelijkheid van de Verkeer. Als een pagina nauwelijks bezoekers bereikt, worden taken te laat of helemaal niet uitgevoerd. Als een CDN elk verzoek vanuit de cache serveert, wordt PHP niet geladen en blijft WP-Cron stil. Dit verklaart waarom geplande publicaties, e-mailtaken of back-ups op sommige installaties onbetrouwbaar lijken. Hoe meer plugins extra taken registreren, hoe dichter de wachtrij wordt en hoe kwetsbaarder de uitvoering wordt.
Waarom Last Cronjobs omvalt
Als de stroom bezoekers toeneemt, nemen ook de cron-controles toe en dus ook de Serverbelasting. Meer gelijktijdige verzoeken concurreren om PHP workers, I/O en database, waardoor cron-aanroepen in time-outs terechtkomen. Latencies stapelen zich op, taken blokkeren elkaar en lange taken verlaten het tijdsvenster. Ik pak dit consequent aan in productieve opstellingen, zoals WP-Cron op productiesites is vaak de oorzaak van trage reactietijden. Onder hoge belasting correleren vertragingen direct met overmatig gebruikte cron triggers. Daarnaast verergeren slecht geschreven taken de situatie omdat ze database scans starten die nog meer bronnen in beslag nemen.
Hostinggrenzen en hun gevolgen
Veel hosters gebruiken een PHP time-out van 30-60 seconden; als een taak deze limiet overschrijdt, zal het systeem de taak hard afbreken. Dit heeft invloed op migratietaken, grote exports, beeldverwerking of massa e-mails. Geheugenlimiet, proceslimieten en snelheidslimieten voor HTTP-loopbacks hebben een soortgelijk effect. Als hier weinig verkeer bijkomt, stapelen gebeurtenissen die moeten plaatsvinden zich op en worden ze te laat of helemaal niet uitgevoerd. Daarom controleer ik eerst de limieten en logs voordat ik de applicatie aanpas. Hierdoor kan ik herkennen of de omgeving knelpunten veroorzaakt of dat individuele taken inefficiënt zijn.
Snelle controle: oorzaken, symptomen, oplossingen
Het volgende overzicht helpt me om foutpatronen op een gestructureerde manier te scheiden en doelgericht te werk te gaan in plaats van lukraak te experimenteren. Elke regel toont een Oorzaak, een zichtbare Symptoom en een onmiddellijke maatregel.
| Oorzaak | Typisch symptoom | onmiddellijke maatregel |
|---|---|---|
| CDN/Reversed Proxy serveert 100% uit cache | Geplande bijdragen komen te laat | WP-Cron ontkoppelen, echte server cron instellen |
| PHP time-out (30-60 s) | Geannuleerde back-ups/exports | Time-out verhogen, taak verdelen in kleinere batches |
| Te veel cron-gebeurtenissen | Merkbare latentie bij piekverkeer | Intervallen rekken, onnodige gebeurtenissen verwijderen |
| Inefficiënte SQL-query's | Databasegebruik neemt met sprongen toe | Indexen instellen, SELECTs afslanken, caching |
| Website met weinig verkeer | Uren van vertragingen | Voer elke 15-60 minuten de cron van het systeem uit |
Ik vul de controle aan met echte meetgegevens uit logboeken en monitoring om aannames te verifiëren en de Oorzaak duidelijk. De tabel vervangt een meting niet, maar kanaliseert hem. Pas als ik weet of de time-out, cache of database beperkend zijn, neem ik de juiste maatregelen. Vervolgens test ik herhaaldelijk en controleer ik of er latere effecten zijn. Op deze manier minimaliseer ik de inspanning en los ik het probleem duurzaam op.
Beste praktijken: Van WP-Cron naar Server-Cron
Ik deactiveer eerst de paginagerichte trigger met UITSCHAKELEN_WP_CRON in wp-config.php: define(‚DISABLE_WP_CRON‘, true);. Vervolgens stel ik een echte systeemcron in die wp-cron.php cyclisch aanroept (bijv. via curl elke 5 minuten voor veel verkeer, elk uur voor weinig verkeer). Hierdoor kan ik de executies loskoppelen van de bezoekersstroom en de Belasting. Tegelijkertijd beperk ik gelijktijdige aanroepen zodat er geen cron stormen ontstaan. Als ik pieken verwacht, verhoog ik de PHP workers en pas ik de time-outs aan. Vooral bij fluctuerend verkeer verminder ik Ongelijke CPU-belasting en kettingreacties voorkomen.
Intervallen, taakontwerp en database
Ik controleer elke gebeurtenis op zijn Interval en rek frequenties op waar dat gerechtvaardigd is. In plaats van elke minuut scan ik elk uur of dagelijks als de taak geen real-time waarde vereist. Ik verdeel lange taken in kleine batches die veilig binnen de PHP time-out draaien. Bij het benaderen van databases stel ik indexen in, verklein ik kolommen en laat ik volledige scans achterwege. Ik cache frequente gegevens om herhalingen te onderscheppen en de Database van onnodig werk. Dit vermindert runtimes en cron executies blijven berekenbaar.
Diagnose in de praktijk: zichtbaarheid creëren
Voordat ik ga verbouwen, wil ik betrouwbare Diagnostische gegevens. Ik begin met de gezondheidsweergave van de WordPress site en activeer logging (WP_DEBUG_LOG) om PHP fouten zichtbaar te maken tijdens cron calls. Vervolgens maak ik een lijst van geplande gebeurtenissen en hun runtimes. In productieve workflows gebruik ik hiervoor herhaalbare stappen:
- Gepaste gebeurtenissen triggeren via WP-CLI: wp cron event run -due-now
- Lijst geplande gebeurtenissen: wp cron gebeurtenissenlijst
- Stel je eigen meetpunten in: Log begin/eindtijd in de taak, inclusief piekgeheugen
- Controleer de databasepagina: Identificeer lange SELECTs en voeg de nodige indexen toe
Als Site Health „Vertraagde cron-uitvoering“ aangeeft, analyseer ik de toegangslogs op wp-cron.php, responscodes en duur. 429/503 duidt op snelheids- of resourcelimieten, 401/403 op blokkering door auth, firewall of WAF. Ik controleer of loopback verzoeken intern zijn toegestaan en of de hostnaam correct resolved. Ik kijk ook naar de „cron“ optie van wp_options om de grootte en leeftijd van de wachtrij te beoordelen en om functiehaken te identificeren die herhaaldelijk falen.
Robuuste server cron configuratie: HTTP, WP-CLI en vergrendeling
Voor productieve omgevingen geef ik de voorkeur aan een Server cron via WP-CLI in plaats van een pure HTTP-aanroep, omdat ik PHP direct start en minder afhankelijk ben van de webserver/proxy. Voorbeeldvarianten die zichzelf hebben bewezen:
- HTTP-variabele, met tijdbudget en stilstand: curl -sS https://domain.tld/wp-cron.php?doing_wp_cron=1 -max-time 55 -connect-timeout 5 >/dev/null
- WP-CLI direct: cd /path/to/installation && /usr/bin/wp cron event run -due-now -quiet
- Vermijd overlappingen: flock -n /tmp/wp-cron.lock -c „/usr/bin/wp cron event run -due-now -quiet“.“
- Verhoog de bronnen specifiek: php -d memory_limit=512M -d max_execution_time=300 wp-cli.phar cron event run -due-now
Ik gebruik flock om parallelle starts te voorkomen, die anders zouden leiden tot dubbele executies en concurrerende databasetoepassingen. Met meerdere instanties (bijv. Blue/Green, Container), sta ik slechts één host toe om de cron uit te voeren en deactiveer hem op de anderen. Op deze manier voorkom ik race-condities in de wachtrij.
Loopbacks, auth en firewalls: typische blokkades
Als cronjobs in „pending“ hangen, wordt de interne cronjob vaak geblokkeerd. Loopback. Ik controleer of Basic-Auth, IP-beperkingen of een WAF verzoeken naar wp-cron.php verhinderen. In beveiligde staging setups sluit ik wp-cron.php uit van authenticatie of sta ik loopbacks toe als uitzondering. Als externe HTTP-aanroepen beperkt zijn, zorg ik ervoor dat mijn eigen domein niet op de blokkadelijst staat. ALTERNATE_WP_CRON kan op korte termijn helpen, maar ik gebruik het alleen tijdelijk en verwijder het weer zodra er een schone server cron actief is.
Overlappingen en idempotentie: taken veilig maken
Veel problemen ontstaan door Gelijktijdige uitvoeringen van dezelfde taak. Daarom installeer ik taakvergrendelingen (bijv. via transient/option), controleer ik of een run al actief is voordat ik begin en beëindig ik de tweede aanroep vroegtijdig. Tegelijkertijd maak ik taken idempotent: als een stap twee keer wordt gestart, leidt dit niet tot dubbele e-mails, bestanden of DB entries. Voor batch taken sla ik offsets/markers op om voortzettingen netjes te controleren en herhalingen te onderscheppen. Dit vermindert gevolgschade als een cron-run onverwacht stopt en later opnieuw start.
Schalen: multiserver, container en multisite
In gedistribueerde omgevingen werk ik met precies één Cron runner. Dit kan een aparte worker container zijn of een vast knooppunt dat alle vereiste gebeurtenissen triggert via WP-CLI. Gedeelde bestandssystemen of gedistribueerde caches helpen om statussen en vergrendelingen consistent te houden tussen instanties. Bij multisite setups controleer ik of Cron goed is gepland voor elk subsite netwerk en of netwerk events de globale wachtrij niet ongecontroleerd overspoelen. Ik controleer ook of de tijdzones per site kloppen, zodat publicaties en tijdvensters correct zijn.
Tijden en tijdzones: voorkom „Gemist schema“.
Een onderschatte factor zijn Tijdzones en de zomertijd. WordPress plant berichten in de tijdzone van de site, terwijl servers vaak in UTC draaien. Ik synchroniseer beide, controleer de tijdzone-instellingen voor implementaties en houd rekening met tijdsveranderingen in het redactionele plan. Als er een „Gemiste planning“ optreedt, controleer ik of de cronqueue overvol is, of publicatiehaken mislukken of dat de servertijd verschuift. Een volgende „wp cron event run -due-now“ ontlaadt de wachtrij terwijl ik de werkelijke oorzaak oplos (cache, time-out, onjuiste tijdzone).
Ontwikkeling, staging en implementaties
In staging-omgevingen deactiveer ik productieve taken (e-mails, exports, webhooks) zodat er geen onbedoelde acties worden geactiveerd. Ik stel DISABLE_WP_CRON in op true en draai mijn eigen test cron met lange intervallen. Voor de go-live maak ik de wachtrij leeg, voer ik de kritieke taken één keer handmatig uit en houd ik de logs goed in de gaten. Na de implementatie worden de nieuwe haken door een gerichte „due-now“ run geactiveerd voordat de caches weer agressief worden. Dit voorkomt verrassingen en houdt de introductiefase rustig.
Foutafhandeling, backoff en herhalingen
Mislukkingen gebeuren. Ik plan ze door Herhalingen met backoff: pas na korte tijd opnieuw proberen, daarna met toenemende afstand. Ik documenteer mislukte stappen met duidelijke codes en context (invoer, duur, geheugen, SQL, HTTP-code). Na N mislukte pogingen markeer ik de gebeurtenis als „vastgelopen“ en informeer ik mezelf via een waarschuwing. Deze scheiding voorkomt eindeloze lussen en geeft me de tijd om de werkelijke oorzaak te verhelpen zonder dat de wachtrij verstopt raakt.
Gereedschap: WP Crontrol en Action Scheduler
Voor de dagelijkse Controle Ik gebruik WP Crontrol om gebeurtenissen rechtstreeks in WordPress te bekijken, te pauzeren of opnieuw in te plannen. Ik gebruik het om hangende haken, dubbele invoer of onjuiste intervallen te herkennen. Voor grote processen gebruik ik Action Scheduler, die taken opsplitst in kleine acties en ze netjes logt. Als een actie mislukt, start ik hem gericht opnieuw op zonder de hele keten in gevaar te brengen. Dit minimaliseert pieken omdat ik niet door een monoliet heen duw, maar eerder Subtaken tactisch. Hierdoor blijven implementaties en onderhoudsvensters voorspelbaar.
Gedeelde hosting, caching en CDN's
In gedeelde omgevingen botsen cron-aanroepen al snel met Grenzen, die ik niet rechtstreeks beheer. Als het CDN en de volledige paginacache dan in werking treden, triggert geen enkele pagina-aanvraag WP-Cron. Ik omzeil dit met een systeemcron en zorg ervoor dat loopback-verzoeken toegankelijk zijn. Waar cron niet betrouwbaar werkt, controleer ik netwerkbeleid, basisauth en firewalls. Een test met een directe curl-aanroep laat zien of verzoeken technisch aankomen. Voor achtergrondinformatie en alternatieven, zie Cronjobs bij shared hosting, omdat typische struikelblokken daar in compacte vorm worden beschreven.
Monitoring en onderhoud in het dagelijks leven
Ik houd de Site-Gezondheid-Dit komt omdat WordPress zichtbaar vertraagde cron-uitvoeringen rapporteert. Ik schrijf ook logboeken om duur, fouten en herhalingen statistisch te analyseren. Dit brengt afwijkingen aan het licht die anders onopgemerkt zouden blijven in de dagelijkse gang van zaken. Ik verwijder of reset verouderde of permanent falende events om de wachtrij slank te houden. Waarschuwingen via e-mail of Slack informeren me als een taak meerdere keren mislukt. Hierdoor kan ik ingrijpen voordat gevolgen zoals gemiste updates of niet-verzonden e-mails schade aanrichten.
Conclusie: Mijn aanpak in het kort
Eerst ontkoppel ik Cron van pagina-oproepen, stel een Server cron en controleer de toegankelijkheid via curl. Vervolgens optimaliseer ik de intervallen, verdeel ik lange taken in batches en verminder ik de databasebelasting. Ik stel logging in, kijk naar foutpaden en pas limieten aan zodat geen enkele taak crasht bij de time-out. Indien nodig gebruik ik Action Scheduler omdat deze lange processen betrouwbaar opsplitst in controleerbare delen. Vervolgens meet ik het effect en stroomlijn ik de cron lijst totdat de wachtrij schoon blijft. Op deze manier draaien geplande taken betrouwbaar, zelfs als de Belasting stijgingen of caches werken agressief.
