Videre til indhold 
WordPress cronjobs fejler under belastning, når sideanmodninger blokerer den interne planlægning, cacher opfanger anmodninger, eller hostinggrænser begrænser lange opgaver. Jeg viser årsager, konsekvenser og konkrete løsninger for at sikre, at opgaver som opdateringer, sikkerhedskopier og planlagte indlæg kører pålideligt.
Centrale punkter
Til at begynde med vil jeg opsummere de vigtigste aspekter kort og klart, før jeg går mere i detaljer og forklarer specifikke trin, som jeg bruger produktivt. Identifikation af problemer og Årsager er i fokus her.
- MekanikWP-Cron udløses ved sideforespørgsler i stedet for via system-cron.
- BelastningHøj trafik og „wordpress cron load“ genererer timeouts.
- CachingKomplet CDN-caching stopper cron-udførelse.
- GrænserPHP-timeouts og ressourcebudgetter annullerer opgaver.
- AfhjælpningServer cron, rene intervaller, logning og tuning.
WP-Cron kort forklaret: Sidekald i stedet for systemservice
Jeg begynder med Grundlæggende idéWordPress kontrollerer, om planlagte opgaver skal udføres ved hver sideanmodning og udløser dem via en intern HTTP-anmodning til wp-cron.php. Denne tilgang kompenserer for den manglende adgang til rigtige serverkroner, men skaber en afhængighed af Trafik. Hvis en side næsten ikke når ud til nogen besøgende, kører opgaverne sent eller slet ikke. Hvis et CDN serverer alle anmodninger fra cachen, indlæses PHP ikke, og WP-Cron forbliver tavs. Det forklarer, hvorfor planlagte publikationer, e-mailjobs eller sikkerhedskopieringer virker upålidelige på nogle installationer. Jo flere plugins, der registrerer yderligere opgaver, jo tættere bliver køen, og jo mere sårbar bliver udførelsen.
Hvorfor load cronjobs vælter
Hvis strømmen af besøgende øges, øges også cron-tjekkene og dermed også Serverbelastning. Flere samtidige anmodninger konkurrerer om PHP-arbejdere, I/O og database, hvilket får cron-kald til at glide ind i timeouts. Latenstider akkumuleres, opgaver blokerer hinanden, og lange opgaver forlader tidsvinduet. Jeg adresserer konsekvent dette i produktive opsætninger, som WP-Cron på produktionssteder er ofte den udløsende faktor for langsomme svartider. Under høj belastning er der en direkte sammenhæng mellem langsommelighed og overbrugte cron-triggere. Desuden forværrer dårligt skrevne opgaver situationen, fordi de starter databasescanninger, der binder endnu flere ressourcer.
Hosting-grænser og deres konsekvenser
Mange hostere bruger en PHP-timeout på 30-60 sekunder; hvis en opgave overskrider dette mærke, afslutter systemet den hårdt. Dette påvirker migreringsjob, store eksporter, billedbehandling eller masse-e-mails. Memory_limit, procesgrænser og hastighedsgrænser for HTTP-loopbacks har en lignende effekt. Hvis der dertil kommer lav trafik, ophobes begivenheder, der skal afvikles, og de afvikles sent eller slet ikke. Derfor tjekker jeg først limits og logs, før jeg justerer applikationen. Det giver mig mulighed for at se, om miljøet forårsager flaskehalse, eller om individuelle opgaver er ineffektive.
Hurtigt tjek: årsager, symptomer, løsninger
Følgende oversigt hjælper mig til at adskille fejlmønstre på en struktureret måde og til at handle målrettet i stedet for at eksperimentere tilfældigt. Hver linje viser en Årsag, en synlig Symptom og en øjeblikkelig foranstaltning.
| Årsag | Typisk symptom | øjeblikkelig foranstaltning |
|---|---|---|
| CDN/Reversed Proxy serverer 100% fra cache | Planlagte bidrag kommer for sent | Afkobl WP-Cron, indstil ægte server-cron |
| PHP-timeout (30-60 s) | Annullerede sikkerhedskopier/eksport | Forøg timeout, del opgaven op i mindre portioner |
| For mange cron-begivenheder | Mærkbar ventetid ved spidsbelastning | Stræk intervallerne, fjern unødvendige begivenheder |
| Ineffektive SQL-forespørgsler | Databaseudnyttelsen øges med stormskridt | Indstil indekser, slank SELECTs, caching |
| Hjemmeside med lav trafik | Timer med forsinkelser | Kør system-cron hvert 15.-60. minut |
Jeg supplerer kontrollen med reelle målinger fra logfiler og overvågning for at verificere antagelser og analysere Årsag helt klart. Tabellen erstatter ikke en måling, den kanaliserer den. Først når jeg ved, om timeout, cache eller database er begrænsende, træffer jeg de rette foranstaltninger. Derefter tester jeg gentagne gange og kontrollerer, om der er nogen efterfølgende effekter. På den måde minimerer jeg indsatsen og løser problemet bæredygtigt.
Bedste praksis: Fra WP-Cron til Server-Cron
Jeg deaktiverer først den sidebaserede trigger med DEAKTIVER_WP_CRON i wp-config.php: define(‚DISABLE_WP_CRON‘, true);. Derefter opsætter jeg en rigtig systemcron, der kalder wp-cron.php cyklisk (f.eks. via curl hvert 5. minut ved høj trafik, hver time ved lav trafik). Dette giver mig mulighed for at afkoble udførelser fra strømmen af besøgende og udjævne Belastning. Samtidig begrænser jeg samtidige kald, så der ikke opstår cron-storme. Hvis jeg forventer spidsbelastninger, øger jeg antallet af PHP-arbejdere og justerer timeouts. Især med svingende trafik reducerer jeg Ujævn CPU-belastning og forhindre kædereaktioner.
Intervaller, opgavedesign og database
Jeg tjekker hver begivenhed for dens Interval og strækker frekvenserne, hvor det er forsvarligt. I stedet for hvert minut scanner jeg hver time eller dagligt, hvis opgaven ikke har brug for realtidsværdi. Jeg opdeler lange jobs i små batches, der kører sikkert inden for PHP-timeout. Når jeg tilgår databaser, indstiller jeg indekser, reducerer kolonner og afstår fra fulde scanninger. Jeg cacher hyppige data for at opfange gentagelser og minimere de Database fra unødvendigt arbejde. Det reducerer runtimes, og cron-eksekveringer forbliver beregnelige.
Diagnose i praksis: skab synlighed
Før jeg bygger om, vil jeg gerne have pålidelige Diagnostiske data. Jeg starter med WordPress-stedets sundhedsvisning og aktiverer logning (WP_DEBUG_LOG) for at gøre PHP-fejl synlige under cron-kald. Derefter lister jeg forfaldne og planlagte begivenheder og deres køretider. I produktive arbejdsgange bruger jeg gentagne trin til dette:
- Udløs forfaldne begivenheder via WP-CLI: wp cron event run -due-now
- Liste over planlagte begivenheder: wp cron event list
- Indstil dine egne målepunkter: Log start/sluttidspunkt i opgaven, inklusive spidsbelastning
- Tjek databasesiden: Identificer lange SELECTs og tilføj nødvendige indekser
Hvis Site Health viser „Delayed cron execution“, analyserer jeg adgangslogs på wp-cron.php, svarkoder og varighed. 429/503 indikerer hastigheds- eller ressourcebegrænsninger, 401/403 indikerer blokering af auth, firewall eller WAF. Jeg tjekker, om loopback-anmodninger er tilladt internt, og om værtsnavnet opløses korrekt. Jeg ser også på „cron“-indstillingen i wp_options for at vurdere køens størrelse og alder og identificere funktionshooks, der gentagne gange fejler.
Robust server cron-konfiguration: HTTP, WP-CLI og låsning
Til produktive miljøer foretrækker jeg en Server cron via WP-CLI frem for et rent HTTP-kald, fordi jeg starter PHP direkte og er mindre afhængig af webserveren/proxyen. Eksempler på varianter, der har bevist deres værd:
- HTTP-variabel, med tidsbudget og standstill: curl -sS https://domain.tld/wp-cron.php?doing_wp_cron=1 -max-time 55 -connect-timeout 5 >/dev/null
- WP-CLI direkte: cd /sti/til/installation && /usr/bin/wp cron event run -due-now -quiet
- Undgå overlapninger: flock -n /tmp/wp-cron.lock -c „/usr/bin/wp cron event run -due-now -quiet“
- Forøg ressourcerne på en målrettet måde: php -d memory_limit=512M -d max_execution_time=300 wp-cli.phar cron event run -due-now
Jeg bruger flock til at forhindre parallelle starter, som ellers ville føre til dobbelte udførelser og konkurrerende databaseadgang. Med flere instanser (f.eks. Blue/Green, Container) tillader jeg kun én host at udføre cron'en og deaktiverer den på de andre. På den måde undgår jeg race conditions i køen.
Loopbacks, auth og firewalls: typiske blokeringer
Hvis cronjobs hænger i „pending“, bliver det interne cronjob ofte blokeret. Loopback. Jeg tjekker, om Basic-Auth, IP-restriktioner eller en WAF forhindrer anmodninger til wp-cron.php. I sikre staging-opsætninger udelukker jeg wp-cron.php fra autentificering eller tillader loopbacks som en undtagelse. Hvis eksterne HTTP-opkald er begrænset, sørger jeg for, at mit eget domæne ikke er på blokeringslisten. ALTERNATE_WP_CRON kan hjælpe på kort sigt, men jeg bruger den kun midlertidigt og fjerner den igen, så snart en ren server-cron er aktiv.
Overlapninger og idempotens: gør opgaver sikre
Mange problemer opstår på grund af Samtidige udførelser af den samme opgave. Derfor installerer jeg opgavelåse (f.eks. via transient/option), tjekker, om en kørsel allerede er aktiv, før den starter, og afslutter det andet kald tidligt. Samtidig gør jeg opgaver idempotente: Hvis et trin startes to gange, fører det ikke til duplikerede e-mails, filer eller DB-poster. Til batchjobs gemmer jeg offsets/markører for at styre fortsættelser rent og opfange gentagelser. Det reducerer følgeskader, hvis en cron-kørsel stopper uventet og genstarter senere.
Skalering: multiserver, container og multisite
I distribuerede miljøer arbejder jeg præcis én Cron-løber. Det kan være en separat worker-container eller en fast node, som udløser alle nødvendige begivenheder via WP-CLI. Delte filsystemer eller distribuerede cacher hjælper med at holde statusser og låse konsistente mellem instanser. I multisite-opsætninger kontrollerer jeg, om Cron er korrekt planlagt for hvert subsite-netværk, og om netværkshændelser ikke oversvømmer den globale kø på en ukontrolleret måde. Jeg sørger også for, at tidszonerne pr. site er korrekte, så publikationer og tidsvinduer er korrekte.
Tider og tidszoner: undgå „missed schedule“
En undervurderet faktor er Tidszoner og skift til sommertid. WordPress planlægger indlæg i webstedets tidszone, mens servere ofte kører i UTC. Jeg synkroniserer begge dele, tjekker tidszoneindstillingerne for implementeringer og tager højde for tidsændringer i den redaktionelle plan. Hvis der opstår en „Missed schedule“, tjekker jeg, om cronqueue'en er overfyldt, om publiceringshooks fejler, eller om servertiden skifter. En efterfølgende „wp cron event run -due-now“ tømmer køen, mens jeg løser den egentlige årsag (cache, timeout, forkert tidszone).
Udvikling, iscenesættelse og udrulning
I staging-miljøer deaktiverer jeg produktive opgaver (e-mails, eksport, webhooks), så der ikke udløses utilsigtede handlinger. Jeg sætter DISABLE_WP_CRON til true og kører min egen test-cron med lange intervaller. Før go-live tømmer jeg køen, udfører de kritiske opgaver en gang manuelt og overvåger logfiler nøje. Efter implementeringen udløser en målrettet „due-now“-kørsel de nye hooks, før cachen bliver aggressiv igen. Det forhindrer overraskelser og holder introduktionsfasen stille.
Fejlhåndtering, backoff og gentagelser
Fejl sker. Jeg planlægger dem ved at Forsøg igen med backoff: Prøv først igen efter kort tid og derefter med stigende afstand. Jeg dokumenterer mislykkede trin med klare koder og kontekst (input, varighed, hukommelse, SQL, HTTP-kode). Efter N mislykkede forsøg markerer jeg begivenheden som „fastlåst“ og informerer mig selv via en advarsel. Denne adskillelse forhindrer endeløse sløjfer og giver mig tid til at rette op på den faktiske årsag uden at tilstoppe køen.
Værktøjer: WP Crontrol og Action Scheduler
Til den daglige Kontrol Jeg bruger WP Crontrol til at se, sætte på pause eller omplanlægge begivenheder direkte i WordPress. Jeg bruger det til at genkende hængende kroge, duplikerede poster eller forkerte intervaller. Til store processer bruger jeg Action Scheduler, som opdeler opgaver i små handlinger og logger dem rent. Hvis en handling fejler, genstarter jeg den målrettet uden at sætte hele kæden over styr. Det minimerer spidsbelastninger, fordi jeg ikke skubber gennem en monolit, men snarere Underopgaver taktisk. Det gør udrulninger og vedligeholdelsesvinduer forudsigelige.
Delt hosting, caching og CDN'er
I delte miljøer kolliderer cron-kald hurtigt med Grænser, som jeg ikke kontrollerer direkte. Hvis CDN og full page cache så træder i kraft, er der ikke en eneste sideanmodning, der udløser WP-Cron. Jeg omgår dette med en system-cron og sørger for, at loopback-anmodninger er tilgængelige. Hvor cron ikke udløses pålideligt, tjekker jeg netværkspolitikker, grundlæggende auth og firewalls. En test med et direkte curl-kald viser, om anmodningerne teknisk set kommer frem. For baggrundsinformation og alternativer henvises til Cronjobs i Shared Hosting, fordi typiske snublesten er beskrevet der i kompakt form.
Overvågning og vedligeholdelse i hverdagen
Jeg beholder Site-sundhedDette skyldes, at WordPress synligt rapporterer forsinkede cron-udførelser. Jeg skriver også logs for at analysere varighed, fejl og gentagelser statistisk. Det afslører uregelmæssigheder, som ellers ville gå ubemærket hen i den daglige drift. Jeg sletter eller nulstiller forældede eller permanent mislykkede begivenheder for at holde køen slank. Advarsler via e-mail eller Slack informerer mig, hvis et job fejler flere gange. Det giver mig mulighed for at gribe ind, før konsekvenser som manglende opdateringer eller usendte e-mails forårsager skade.
Konklusion: Min tilgang kort fortalt
Først afkobler jeg Cron fra sidekald, sætter en Server cron og tjekker tilgængeligheden via curl. Derefter optimerer jeg intervaller, opdeler lange opgaver i batches og reducerer databasebelastningen. Jeg opsætter logning, ser på fejlveje og justerer grænserne, så ingen opgaver går ned ved timeout. Hvis det er nødvendigt, bruger jeg Action Scheduler, fordi den pålideligt opdeler lange processer i kontrollerbare dele. Derefter måler jeg effekten og strømliner cron-listen, indtil køen forbliver ren. På denne måde kører planlagte opgaver pålideligt, selv om Belastning stiger eller cacher arbejder aggressivt.
