WooCommerce y muchas extensiones usan Action Scheduler para webhooks, suscripciones, email, limpieza y sincronización. Una cola Pending creciente significa que se crea trabajo más rápido que se completa; muchos Failed iguales indican un callback incapaz de terminar.
No borres la cola para reducir el número. Puede contener pagos, reembolsos o fulfilment que aún requieren conciliación.
Mide el backlog
En WooCommerce > Estado > Acciones programadas registra Pending, Failed, In-progress y la hora más antigua.
- edad de la pendiente más vieja
- nuevas acciones por minuto
- completadas por minuto
- hooks con más fallos
- duración media y máximaConsulta argumentos solo con autorización; pueden contener IDs de cliente o pedido.
Confirma que se invoca el runner
WordPress activa cron con tráfico. Revisa DISABLE_WP_CRON y si existe cron real.
Usa cPanel o Plesk para llamar al sitio con PHP/HTTP soportado y frecuencia razonable. Confirma sitio y versión PHP. No ejecutes varios crons solapados sin medir concurrencia.
En multisite, el scheduler debe alcanzar la tienda donde viven las acciones. Llamar solo al sitio principal puede dejar otra cola inmóvil; revisa cada tienda.
Comprueba en los logs que cada invocación inicia realmente un runner y cuántas acciones reclama. Una respuesta HTTP 200 de wp-cron.php no prueba progreso. Compara el ID más antiguo y el recuento completado antes y después de varias ejecuciones.
Lee el primer fallo repetido
Agrupa acciones por hook y error, no abras únicamente la última. Relaciona un caso con logs PHP y del proveedor.
Una función ausente apunta a incompatibilidad; 401 a credenciales; timeout a resultado externo desconocido; deadlock a escrituras concurrentes. Corrige la causa común antes de reintentar un lote.
Comprueba workers y límites
El runner necesita procesos PHP y memoria. Si están ocupados por requests lentos, cron llega pero no avanza.
Revisa gráficos, fatals y saturación. Aumenta capacidad solo tras saber si una acción monopoliza cada worker. Divide importaciones en unidades acotadas; una acción no debería procesar todo el catálogo.
Calcula throughput necesario: nuevas acciones por minuto frente a completadas. Si la cola crece incluso sin errores, reduce el coste por tarea, ajusta lotes o añade capacidad con límites. Si solo un hook consume todo el tiempo, sepáralo para que no bloquee pagos y emails.
Revisa locks y tablas
Action Scheduler reclama y registra trabajo en MySQL. Consultas lentas, disco lleno o claims abandonados reducen throughput.
Usa métricas y herramientas oficiales compatibles con la versión. Haz backup antes de mantenimiento. No truncar tablas: el historial sirve para deduplicar, auditar y diagnosticar.
Revisa espacio, índices esperados y consultas de claims. Un disco casi lleno puede impedir escribir logs o liberar acciones aunque PHP siga respondiendo. Corrige el almacenamiento antes de reintentar, porque más runners aumentarían la presión.
Haz callbacks idempotentes
La misma acción puede repetirse después de timeout. Pago, stock y fulfilment deben reconocer una operación completada.
$order = wc_get_order( $order_id );
if ( ! $order ) {
throw new RuntimeException( 'Pedido no disponible para la tarea' );
}Validar es solo el inicio. Guarda una referencia externa estable y consulta resultados inciertos antes de reintentar. Nunca registres secretos o payloads personales.
Recupera por lotes controlados
Concilia acciones sensibles con proveedor y estado del pedido. Corrige la raíz, ejecuta una de bajo riesgo y verifica efectos.
Procesa un lote limitado observando tasa de finalización, PHP, MySQL y límites externos. Detente ante duplicados o fallos nuevos. Archiva/cancela solo si la operación comercial es objetivamente obsoleta.
Define tamaño, pausa y criterio de parada antes de empezar. Tras cada lote compara estados externos, no solo Completed: una acción puede finalizar localmente y dejar un envío o webhook rechazado. Conserva una lista de referencias procesadas.
Evita otro bloqueo silencioso
Alerta por edad de Pending, tasa de error y crecimiento, no por el total histórico. Prueba cron tras migraciones, cambios PHP o reglas de seguridad.
Completa un pedido controlado y confirma que email, webhook, stock y tareas externas terminen una vez. El mantenimiento recurrente debe tratar la latencia de cola como salud transaccional.