Pablo Román
Profesional de la comunicación y el diseño web. Trabajo con contenidos, SEO y WordPress, y sigo de cerca el análisis del mercado laboral y las tendencias de empleo y formación.

Entras en WooCommerce > Estado > Acciones programadas y encuentras cientos o miles de tareas pendientes. Algunas llevan horas esperando. Otras aparecen como fallidas. Limpias unas cuantas y, al poco tiempo, vuelven a acumularse.
La primera tentación suele ser borrar la cola.
No empieces por ahí.
Una cola grande de acciones programadas no es necesariamente un problema. WooCommerce y muchos de sus plugins utilizan Action Scheduler para ejecutar procesos en segundo plano. Lo importante no es cuántas acciones aparecen, sino si se están procesando al ritmo esperado, cuáles se atascan y qué plugin está generándolas.
Si la cola crece continuamente, hay acciones vencidas desde hace mucho tiempo o aparecen fallos repetidos, entonces sí conviene investigar.
Action Scheduler es un sistema para gestionar tareas en segundo plano dentro de WordPress. WooCommerce lo utiliza, y también lo hacen numerosas extensiones.
Entre otras cosas, esas tareas pueden intervenir en:
WooCommerce permite examinarlas desde:
WooCommerce > Estado > Acciones programadas
Dependiendo de la instalación también pueden encontrarse en:
Herramientas > Acciones programadas
La propia documentación de WooCommerce explica que estas tareas se ejecutan en segundo plano y que Action Scheduler se apoya normalmente en WP-Cron para activar su procesamiento.
Esto último es importante: una cola atascada puede ser un problema de Action Scheduler, pero también puede ser consecuencia de que WP-Cron no esté funcionando correctamente, de que una tarea falle una y otra vez o de que un plugin esté generando trabajo más rápido de lo que el servidor consigue procesarlo.
No existe una cifra universal a partir de la cual podamos decir que una tienda tiene demasiadas acciones.
Una tienda con mucho tráfico, suscripciones, integraciones externas y automatizaciones puede ejecutar continuamente miles de procesos. Otra tienda mucho más pequeña puede tener solo unas decenas.
Por eso, mirar únicamente el contador puede llevar a conclusiones equivocadas.
Hay que observar el comportamiento de la cola.
Una cola puede ser razonablemente normal cuando:
La situación resulta más sospechosa cuando:
En ese caso no tienes simplemente una cola grande. Tienes que averiguar qué está impidiendo que la cola avance.
La pantalla de acciones programadas contiene una pista especialmente útil: el hook.
El nombre del hook indica qué tarea se está intentando ejecutar.
En lugar de fijarte solo en el número total de acciones pendientes, comprueba:
Action Scheduler permite filtrar por estados como pendientes, completadas, fallidas o en curso y consultar el registro de determinadas ejecuciones. Es precisamente una de las funciones para las que se creó su panel de administración.
Si descubres, por ejemplo, 5.000 acciones pendientes pero 4.800 pertenecen al mismo hook, acabas de reducir considerablemente el problema.
Ya no estás investigando «por qué WooCommerce tiene tantas tareas».
Estás investigando qué está haciendo el plugin responsable de ese hook y por qué sus tareas no terminan correctamente.
Las acciones fallidas suelen proporcionar más información que las pendientes.
Abre alguna de ellas y revisa su registro.
Busca patrones:
Una acción puede fallar por razones muy diferentes:
Por eso, eliminar una acción fallida no corrige necesariamente nada.
Si el plugin continúa intentando programarla, volverá a aparecer.
Es parecido a borrar un mensaje de error sin resolver aquello que lo está generando.
Si además observas errores PHP, cambios recientes de versión o plugins antiguos, conviene ampliar el diagnóstico. En cómo actualizar un WordPress antiguo sin romperlo explicamos cómo revisar dependencias y compatibilidad antes de realizar cambios importantes.
Action Scheduler y WP-Cron no son exactamente lo mismo, pero están estrechamente relacionados.
Por defecto, Action Scheduler utiliza un proceso activado mediante WP-Cron para poner en marcha su cola. WooCommerce también señala esta dependencia en su documentación.
Por tanto, si WP-Cron no se ejecuta correctamente, Action Scheduler puede empezar a acumular trabajo.
WordPress no utiliza cron exactamente igual que un servidor Linux tradicional. WP-Cron comprueba las tareas programadas cuando se producen determinadas peticiones al sitio.
Esto puede provocar problemas, entre otros casos, cuando:
wp-config.php;wp-cron.php fallan;Si tienes acceso a WP-CLI, WordPress dispone de una comprobación específica:
wp cron test
También permite examinar los eventos programados y ejecutar los que ya deberían haberse procesado.
No obstante, ejecutar manualmente toda la cola no debería convertirse en la solución permanente. Si el problema reaparece, debes encontrar la causa.
Hay un segundo escenario muy distinto.
WP-Cron funciona. Action Scheduler funciona. Las tareas se ejecutan.
Pero entran más trabajos de los que salen.
Puede ocurrir con:
En este caso, vaciar manualmente la cola tampoco resuelve el problema.
Necesitas averiguar:
¿qué está generando tantas acciones y cuánto tarda cada una en ejecutarse?
Aquí es donde el nombre del hook y el grupo vuelven a ser fundamentales.
También conviene comprobar si el atasco apareció después de instalar o actualizar algún plugin.
Si coincide claramente con un cambio reciente, esa correlación merece investigarse, aunque por sí sola no demuestra que el plugin sea responsable.
Una cola problemática puede tener consecuencias más allá de las tareas que se retrasan.
Action Scheduler utiliza la base de datos y ejecuta procesos PHP. Si existe un volumen anormal de acciones, consultas pesadas o tareas fallando continuamente, puede aumentar la carga de la instalación.
Pero conviene evitar otro diagnóstico demasiado fácil:
wp-admin va lento → Action Scheduler es el culpable.
No necesariamente.
Un administrador lento también puede deberse a consultas de plugins, Heartbeat, autoload, llamadas a servicios externos, WooCommerce, cron, base de datos o recursos insuficientes del servidor.
Por eso tenemos una guía específica sobre qué comprobar cuando WordPress va rápido por fuera pero wp-admin es muy lento.
Si tienes ambos síntomas —wp-admin lento y miles de acciones atrasadas— sí existe una relación que merece comprobarse.
Puede servir como prueba diagnóstica.
Si ejecutas una acción pendiente y:
el problema puede estar relacionado con la frecuencia con la que se está activando el procesamiento.
Si al ejecutarla:
el problema probablemente está en esa tarea o en aquello de lo que depende.
La propia interfaz de Action Scheduler permite ejecutar acciones pendientes manualmente.
Hazlo con unas pocas tareas representativas antes de intentar procesar miles de golpe.
En sitios grandes, procesar colas enormes desde peticiones web puede no ser la mejor opción.
Action Scheduler dispone de comandos específicos para WP-CLI y su propia documentación recomienda este método para colas grandes o tareas de larga duración, ya que evita algunas de las limitaciones que introduce una petición web normal.
Por ejemplo, permite procesar la cola mediante:
wp action-scheduler run
También puede limitarse el procesamiento por lotes, hooks o grupos.
Esto es útil para administradores y desarrolladores, pero hay una diferencia importante entre procesar una cola atrasada y resolver la causa por la que se atrasó.
Después de vaciarla hay que volver a observarla.
Si unas horas después vuelve a crecer al mismo ritmo, el problema continúa ahí.
No como primera medida.
Una acción pendiente existe porque algún componente de la web espera que ocurra algo.
Puede tratarse de una tarea prescindible, pero también de:
Borrar indiscriminadamente las acciones puede impedir que esos procesos terminen.
Con las acciones fallidas ocurre algo parecido. Limpiarlas puede resultar razonable una vez que has identificado el problema y sabes que ya no son necesarias, pero borrarlas no arregla la causa del fallo.
Y si el plugin responsable sigue activo y continúa generándolas, probablemente regresarán.
Otro consejo frecuente consiste en entrar en phpMyAdmin y vaciar las tablas utilizadas por Action Scheduler.
Es una medida mucho más agresiva y raramente debería ser el primer paso.
Antes debes saber:
Modificar directamente la base de datos sin entender estas relaciones puede convertir un problema de rendimiento en un problema funcional.
La limpieza de tablas puede formar parte de tareas de mantenimiento muy concretas, pero no debe confundirse con «optimizar WordPress». En cómo limpiar la base de datos de WordPress sin tocar código explicamos qué información suele acumularse y por qué conviene distinguir datos prescindibles de datos que todavía necesita algún plugin.
Si encuentras una cola anormalmente grande, este orden suele proporcionar bastante más información que empezar borrando:
¿Las acciones pendientes son de hace minutos, horas o varios días?
Una instantánea aislada dice poco. La tendencia dice mucho más.
Localiza qué nombres se repiten.
Si un hook representa la mayor parte de la cola, investiga primero ese componente.
Consulta sus registros y busca errores repetidos.
No desactives media instalación a ciegas. Intenta establecer primero qué componente está relacionado.
Especialmente si muchas tareas diferentes están retrasadas simultáneamente.
Te permitirá saber si las tareas pueden terminar o fallan al ejecutarse.
CPU, memoria, procesos PHP, logs y base de datos pueden aportar información decisiva.
Actualizaciones, nuevas integraciones, migraciones, importaciones o cambios de PHP.
Si el problema apareció después de que el hosting cambiase PHP, consulta también qué comprobar cuando tu hosting va a cambiar la versión de PHP.
Solo entonces tiene sentido limpiar las acciones antiguas que hayan quedado sin utilidad.
Hay una señal especialmente útil.
Si encuentras 10.000 tareas atrasadas pertenecientes a un plugin y, tras desactivarlo o corregir su configuración, dejan de generarse nuevas acciones, Action Scheduler probablemente no era la causa.
Era el mensajero.
Lo mismo sucede si WP-Cron está completamente detenido: Action Scheduler no puede procesar adecuadamente su trabajo porque el mecanismo que debe ponerlo en marcha no está funcionando.
El diagnóstico debe distinguir entre:
quién genera las tareas → quién las ejecuta → por qué no terminan.
Confundir esas tres cosas explica muchas de las soluciones que solo funcionan durante unas horas.
Las copias programadas son un buen ejemplo de por qué conviene comprobar los procesos automáticos de una instalación WordPress.
Puedes tener un plugin de backup correctamente configurado y descubrir meses después que sus tareas programadas no estaban ejecutándose como esperabas.
Por eso una copia no debería considerarse válida simplemente porque «el plugin está instalado».
Hay que comprobar también que realmente se genera y puede restaurarse. Lo explicamos con detalle en copias de seguridad en WordPress: la diferencia entre creer que las tienes y saber que funcionan.
En una instalación WooCommerce activa, especialmente si genera ventas, seguiría esta secuencia:
Es el mismo principio que recomendamos para actualizar WordPress sin romper una web en producción: primero entender dependencias y disponer de una forma fiable de volver atrás.
Encontrar miles de acciones programadas puede impresionar, pero el número por sí solo no explica qué ocurre.
La pregunta útil no es:
«¿Cómo borro las acciones de WooCommerce?»
Es:
«¿Qué proceso está generando estas acciones, por qué no se están ejecutando al ritmo esperado y qué dejaría de funcionar si simplemente las elimino?»
Esa diferencia evita muchas limpiezas inútiles y, sobre todo, permite encontrar problemas que de otro modo reaparecerían poco después.
Si tu WooCommerce acumula acciones pendientes, la administración se ha vuelto lenta o determinados procesos automáticos están fallando, conviene revisar el conjunto de la instalación. Una cola descontrolada puede estar relacionada con cron, plugins, PHP, base de datos o recursos del servidor.
En una web de empresa, este tipo de diagnóstico forma parte de un mantenimiento WordPress que no se limita a instalar actualizaciones: también implica comprobar que los procesos que deberían ejecutarse en segundo plano realmente lo hacen.