Kort svar: Nogle få handlinger, der er kortvarigt forfaldne, er normalt på et WordPress-site, fordi køen blandt andet startes af WP-Cron og besøg. En voksende kø eller mange handlinger, der er mere end et døgn gamle, kræver diagnose. Filtrer efter status, hook og gruppe, åbn handlingsloggen, og find det plugin, der ejer jobbet. Kør ikke alt manuelt og slet ikke failed/pending-jobs uden at kende deres forretningseffekt.
Fagligt gennemgået: 28. august 2026
Kontrolgrundlag: WordPress 7.1, WooCommerce 11.0.1 og PHP 8.4.23 på isoleret staging samt aktuel produktdokumentation. Køens størrelse og acceptable forsinkelse afhænger af butikkens egne hooks og driftsmønster.
Action Scheduler behandler blandt andet mails, webhooks, betalinger, lagerjobs og abonnementer. “Forfalden” beskriver tidspunktet, ikke automatisk en fejl. En handling kan stå få minutter over tid og blive kørt ved næste runner. Det alvorlige signal er alder, vækst, gentagne failures og den forretningsfunktion, hooket tilhører.
På denne side
Pending venter på planlagt tidspunkt eller runner. In-progress er claimet af en proces og kan være legitimt aktiv; en gammel claim kan dog pege på timeout/crash. Failed har gennemført et forsøg, som schedulerens log registrerer som mislykket. Løsningen er derfor ikke “kør alle”: en pending backlog kræver runnerkapacitet, mens repeated failed kræver rettelse af handleren.
Completed-historik er nyttig som throughput-baseline. Hvis 500 jobs gennemføres pr. time, og 50 nye kommer til, falder køen. Hvis 600 nye kommer til, vokser den trods en fungerende runner.
Denne optælling er dit før-bevis. Et screenshot af “1000 pending” uden alder og hookfordeling kan ikke afgøre, om køen er fastlåst eller blot arbejder.
| Fund | Sandsynlig forklaring | Kontrol | Næste skridt |
|---|---|---|---|
| Få jobs, minutter forfaldne | Normal trafik-/cronforsinkelse | Ny status efter 10–15 min. | Observer, ingen ændring |
| Kø vokser mellem to målinger | Runner kan ikke følge med eller jobs fejler | Alder, throughput og logs | Find flaskehals/hookejer |
| Kun ét hook fejler | Plugin-/integrationsfejl | Handlingslog og pluginlog | Ret ejerpluginet |
| Alle hooks er forfaldne | WP-Cron, loopback eller serverproblem | Site Health og HTTP-log | Ret runner-infrastruktur |
| Mange In-progress sidder fast | Timeout, process-crash eller lock | Action log og PHP-worker | Eskalér med timestamp |
| Failed har samme fejltekst | Reproducerbar kode-/API-fejl | En repræsentativ log | Ret årsagen før retry |
| Køen eksploderer efter import/opdatering | Forventet batch eller regression | Jobgruppe og release-tid | Throttle/rollback efter ejerens design |
Oversæt hooknavnet til funktionen: sender det mails, fornyer abonnementer, leverer webhooks, synkroniserer lager eller rydder cache? Et kosmetisk analysejob og et betalingsjob har ikke samme prioritet. Hvis ejeren er ukendt, søg hooknavnet i pluginfilerne på staging eller send det til udvikleren. Slet ikke jobbet for at få tælleren til nul.
Loggen viser oprettelse, forsøg, runner og fejl. Kopiér kun den relevante redigerede fejltekst og action-ID. Se efter PHP-fatal, manglende callback, API-timeout, ugyldig ordre/reference eller memory/time limit. Ret den første konkrete fejl, ikke den efterfølgende kø.
Action Scheduler startes normalt via WP-Cron og kan fortsætte med asynkrone loopback-kald. Hvis Site Health viser et cron- eller loopbackproblem, test det specifikke endpoint og se webserver-/WAF-log. En sikkerhedsregel må ikke åbnes bredt; dokumenter den præcise blokerede request.
Lavtrafik- og staging-sites kan behandle sjældnere, fordi WP-Cron afhænger af aktivitet. En rigtig server-cron kan være relevant, men den skal koordineres med hosting og den eksisterende DISABLE_WP_CRON-opsætning. Slå ikke WP-Cron fra, før en ekstern runner er verificeret.
Efter backup og kun når hookets sideeffekt er kendt kan en enkelt pending handling køres fra admin. Observer log, runtime og resultat. Kør ikke betalings-, refund-, mail- eller fulfillmentjobs manuelt uden ejerens procedure.
Hvis én handling lykkes, men køen fortsat vokser, er throughput problemet. Hvis den fejler identisk, er koden/integrationen problemet.
Opdater eller rollback den ansvarlige udvidelse på staging, korriger credentials/destination uden at eksponere dem, eller ret den eksterne API-fejl. Gentag med én testhandling. Failed-jobs retryes kun, hvis handleren er idempotent og leverandøren beskriver det som sikkert.
Store køer bør behandles med overvåget server-/WP-CLI-runner af hosting eller udvikler. Højere batch, concurrency og time limit kan øge database-, PHP- og API-belastning voldsomt. Tag før-/efter-målinger af CPU, memory, database locks, fejlrate og frontend-responstid. Stop ved degradering.
Completed/canceled historik kan normalt ryddes af schedulerens housekeeping. Failed-handlinger er diagnosebevis. Ryd kun gamle failures efter retentionpolitik, backup og bekræftet løsning. Pending jobs må ikke slettes som “oprydning”.
Brug tabellen som arbejdsark med egne observationer. Hvis den deles med andre, skal tal og hooknavne være relevante, reproducerbare og anonymiserede:
| UTC-tid | Pending | Ældste pending | In-progress | Failed | Completed siden sidst | Nye siden sidst |
|---|---|---|---|---|---|---|
| Startmåling | Notér antal | Notér alder | Notér antal | Notér antal | — | — |
| Efter 15 min. | Notér antal | Notér alder | Notér antal | Notér antal | Beregn forskel | Beregn forskel |
| Efter 60 min. | Notér antal | Notér alder | Notér antal | Notér antal | Beregn forskel | Beregn forskel |
Et enkelt snapshot kan ikke vise retningen. Mindst tre målinger med samme filter afslører, om køen drænes, er stabil eller vokser. Segmenter derefter efter hookgruppe; et sundt analysejob kan ellers skjule en fastlåst betalingsgruppe i totalen.
Hvis et recurring job fejler, kan en ny forekomst allerede være planlagt. Find både den failed instans og den næste pending. At slette den gamle failure stopper ikke producenten. Ret koden, konfigurationen eller det eksterne API, og bekræft derefter at næste planlagte test kører korrekt.
Se ikke kun på, hvor mange jobs der bliver gennemført. Sammenlign gennemførte og nye jobs i samme interval. Hvis runneren gennemfører 300 handlinger på en time, mens plugins opretter 420, vokser backloggen med 120, selv om loggen er fuld af succeser. Den ældste pending vil typisk også blive ældre.
Segmentér beregningen efter hook eller gruppe. En stor strøm af hurtige cachejobs kan få total throughput til at se sundt ud, mens en betalingsgruppe ikke flytter sig. For hver kritisk gruppe noteres nytilgang, gennemførte, fejl og alderen på den ældste handling. Det er den konkrete servicehastighed, der afgør, om kapacitet eller kode skal rettes.
Brug også runtimefordelingen. Hvis de fleste handlinger tager under et sekund, men ét API-hook gentagne gange bruger hele timeoutvinduet, kan det ene hook blokere workers og skabe kø for alle andre. Ret eller isolér den langsomme integration, før globale batchgrænser hæves.
En overvåget runner skal have klare stopkriterier: stigende fatal-rate, database locks, checkoutforværring, hukommelsesfejl eller gentagne eksterne API-afvisninger. Notér baseline for frontend og checkout før køen behandles, og stop hvis driften forringes mærkbart.
Kørsel må heller ikke fortsætte, hvis et hook viser ikke-idempotente sideeffekter. En “succesfuld” genkørsel kan sende en mail, hæve en betaling eller oprette en fragtlabel igen. Når hookets kontrakt er ukendt, er leverandørens dokumentation eller udviklerens kodegennemgang næste skridt – ikke en større batch.
Stop den nye runner eller sænk batch/concurrency til den dokumenterede tidligere værdi. Gendan pluginversion eller cronkonfiguration fra backup. Afbryd ikke en in-progress betaling eller fulfillmentproces uden systemejerens procedure.
Pluginudvikleren skal have hook, action-ID, args i anonymiseret form, log og version. Hosting skal have køvækst, cron-/loopbackrequest, serverfejl og ressourcegraf. Se WooCommerce hosting hos Hostious ved server-side queue-drift.
Køen bør ikke afhænge af, om der tilfældigvis kommer besøgende. På WooCommerce hosting hos Hostious sættes et rigtigt cron-job op fra start, netop derfor.
Få kortvarigt forfaldne er normalt. En voksende kø eller handlinger, der er timer/dage gamle, betyder at køen ikke bliver kørt – typisk fordi WP-Cron ikke udløses pålideligt.
Erstat WP-Cron med et rigtigt server-cronjob, der kalder wp-cron.php hvert minut eller kører via WP-CLI. Så er køen uafhængig af besøgstal og loopback-problemer.
Kun fejlede/annullerede og kun når du ved, hvilket plugin de tilhører. Afventende handlinger kan være mails, lagersync og abonnementstræk – kør dem frem for at slette dem.
Gem statusfanernes tællinger, hookfilteret, en anonymiseret handlingslog og Site Health-resultatet for cron og loopback. Notér antal og alder pr. hook, fordi 500 ventende oprydningsjobs ikke har samme forretningsrisiko som fem forsinkede abonnementsbetalinger.
Mål mindst tre tidspunkter med samme filtre. En CSV med status, alder og runnerens gennemløb gør udviklingen synlig. Kør kun en ufarlig repræsentativ testhandling, og bekræft dens resultat i både Action Scheduler-loggen og det system, den skulle påvirke. Testen er først overbevisende, når der ikke opstår nye fejl i observationsperioden.
