Lo primero que hay que entender: Action Scheduler es la cola de tareas que WooCommerce y muchas extensiones utilizan para ejecutar webhooks, suscripciones, emails, actualizaciones de stock y procesos en segundo plano. Miles de acciones vencidas son un síntoma, no el diagnóstico: puede faltar ejecución, puede haber un hook que falla o la cola puede crecer más rápido de lo que se procesa.
Mide el retraso antes de borrar nada
Cuenta las acciones pendientes, fallidas y en curso por hook y grupo. Anota la hora de la acción pendiente más antigua y el ritmo al que aparecen nuevas. Así puedes distinguir una cola histórica estable de una incidencia que sigue creciendo.
Evidencia que identifica el cuello de botella
- Acciones pendientes más antiguas y hook que las creó.
- Mensajes de error e historial de reintentos de los grupos dominantes.
- Frecuencia real con la que se ejecuta WP-Cron o el runner de Action Scheduler.
- Tamaño de tablas, claims bloqueados, timeouts y memoria PHP durante un lote controlado.
Cuatro causas que exigen soluciones distintas
- Runner sin ejecución: WP-Cron o el runner del servidor se inicia demasiado poco.
- Callback fallido: una integración genera excepciones o timeouts repetidamente.
- Exceso de producción: un plugin programa más acciones de las que los workers pueden consumir.
- Presión de base de datos: tablas grandes o consultas lentas encarecen cada lote.
Recupera la cola sin provocar una segunda incidencia
- Pausa o limita el productor si el número de pendientes sigue aumentando.
- Corrige el hook que más falla antes de aumentar la concurrencia.
- Procesa las acciones vencidas en lotes limitados mientras vigilas CPU, base de datos y efectos de negocio.
- Cuando el sistema ya sea estable, limpia el histórico completado o fallido según la retención necesaria.
¿Problema del runner o de la aplicación?
Si apenas empieza ninguna tarea, revisa WP-Cron y los eventos que no se ejecutan. Si el runner funciona pero un grupo devuelve errores de autenticación, compáralo con el diagnóstico de webhooks 401/403 de WooCommerce. Aumentar workers antes de separar ambas causas solo puede acelerar el error.
No ejecutes toda la cola vencida de golpe
Un replay masivo puede enviar emails antiguos, repetir llamadas externas, activar procesos de suscripción o saturar la base de datos. Hay que decidir qué grupos se pueden reprocesar y cuáles deben conciliarse antes.
Cómo verificar la recuperación
La cola vuelve a estar sana cuando edad y volumen bajan a una línea base estable, los hooks críticos terminan una sola vez sin fallos repetidos, el sistema consume el trabajo nuevo al mismo ritmo o más rápido que lo crea y PHP y base de datos se mantienen estables.