El primer que cal entendre: Action Scheduler és la cua de tasques que WooCommerce i moltes extensions utilitzen per executar webhooks, subscripcions, correus, actualitzacions d’estoc i processos en segon pla. Milers d’accions vençudes són un símptoma, no el diagnòstic: pot faltar execució, pot haver-hi un hook que falla o la cua pot créixer més ràpid del que es processa.
Mesura el retard abans d’esborrar res
Compta les accions pendents, fallides i en curs per hook i grup. Anota l’hora de l’acció pendent més antiga i el ritme al qual n’apareixen de noves. Això permet distingir una cua històrica estable d’una incidència que encara està creixent.
Evidència que identifica el coll d’ampolla
- Accions pendents més antigues i hook que les ha creat.
- Missatges d’error i historial de reintents dels grups dominants.
- Freqüència real amb què s’executa WP-Cron o el runner d’Action Scheduler.
- Mida de les taules, claims bloquejats, timeouts i memòria PHP durant un lot controlat.
Quatre causes que requereixen solucions diferents
- Runner que no arrenca: WP-Cron o el runner de servidor s’executa massa poc.
- Callback que falla: una integració genera excepcions o timeouts repetidament.
- Excés de producció: un plugin programa més accions de les que els workers poden consumir.
- Pressió de base de dades: taules grans o consultes lentes encareixen cada lot.
Recupera la cua sense provocar una segona incidència
- Pausa o limita el productor si el nombre de pendents encara augmenta.
- Corregeix el hook que més falla abans d’augmentar la concurrència.
- Processa les accions vençudes en lots limitats mentre controles CPU, base de dades i efectes de negoci.
- Quan el sistema ja sigui estable, neteja l’historial completat o fallit segons la retenció necessària.
Problema de runner o de l’aplicació?
Si gairebé cap tasca comença, revisa WP-Cron i els esdeveniments que no s’executen. Si el runner funciona però un grup retorna errors d’autenticació, compara’l amb el diagnòstic de webhooks 401/403 de WooCommerce. Augmentar workers abans de separar les dues causes només pot accelerar l’error.
No executis tota la cua vençuda de cop
Un replay massiu pot enviar correus antics, repetir crides externes, activar processos de subscripció o saturar la base de dades. Cal decidir quins grups es poden reprocessar i quins s’han de conciliar abans.
Com verificar la recuperació
La cua torna a estar sana quan edat i volum baixen a una línia base estable, els hooks crítics acaben una sola vegada sense errors repetits, el sistema consumeix les tasques noves al mateix ritme o més ràpid que les crea i PHP i base de dades es mantenen estables.
CRITERI D’INCIDENT WP REPAIR
Reconstrueix la incidència abans de corregir-la
La mida de la cua per si mateix no revela si les tasques són lentes, falles, bloquejades per WP-Cron o si es produeixen més ràpid del que s' executen.
- 1
Compti les accions pendents, fallides i en curs per ganxo i grup.
- 2
Inspecciona les accions més antigues, intenta errors registres i crida de retorn.
- 3
Comprova WP-Cron desencadenar la salut i la freqüència del corredor.
- 4
Mesura la mida de la base de dades, els bloqueigs de reclamació i els recursos de PHP durant el processament.
Què ha de quedar verificat
- L'edat i la mida de la cua tornen a una línia de base establa.
- Els ganxos crítics es completen una vegada sense errors repetits.
- WP-Cron, base de dades i PHP romanen sans durant el rendiment normal.
Fonts tècniques oficials
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
És segur executar totes les accions pendents alhora per eliminar el retard ràpidament?+
No. Les accions endarrerides poden incloure enviar correus electrònics de clients, cobrar pagaments, o escriure grans quantitats de dades, per la qual cosa el processament de tots ells alhora en els riscos de producció de càrrecs duplicats, missatges spam, o una sobrecàrrega de base de dades.
Una cua gran sempre vol dir que el lloc està sota càrrega pesada?+
No necessàriament. Un gran retard pot significar que WP-Cron en si mateix està trencat i el corredor rara vegada comença, una integració específica està fallant repetidament i obstruint la cua, o un plugin està produint accions més ràpides del que poden ser processades, cadascuna necessita una solució diferent.
He d'apujar la taxa de processament Action Scheduler abans de trobar el ganxo de fallada?+
No. La guia recomana reparar primer el ganxo dominant fallit, abans d’augmentar el rendiment, perquè l’augment de la velocitat de processament en una cua amb un callback trencat simplement repeteix el mateix error més ràpid.
És segur eliminar les antigues accions acabades i fallides per reduir la base de dades?+
Només després de la recuperació, i d’acord amb les necessitats de retenció. L’historial de neteja és un pas vàlid, però ha de succeir després que la causa arrel del retard se solucioni, no com un substitut per diagnosticar per què les accions s'acumulen.