Una historia real sobre cómo 2.000 tareas atascadas y un plugin de Facebook fuera de control casi tumban un negocio, y cómo lo arreglamos paso a paso.
El síntoma que todos temen
Imagínate esto: es martes por la mañana. Tu campaña de marketing está activa, pero los clientes te escriben diciendo que el sitio web va lentísimo. Peor aún, tu equipo de ventas nota que los pedidos nuevos no están llegando a tu CRM (en este caso, Avify).
El pánico empieza a cundir. ¿Es el hosting? ¿Nos hackearon?
Esta semana atendimos un caso exacto así en Pymesmodernas. El diagnóstico inicial del cliente fue: “La integración con Avify rompió mi sitio”.
Como socios estratégicos, sabemos que en e-commerce rara vez la primera impresión es la correcta. Había que mirar bajo el capó.
Paso 1: Entrando a la sala de máquinas (El diagnóstico)
Cuando un sitio WooCommerce se pone lento y las cosas dejan de funcionar automáticamente (como enviar correos o sincronizar pedidos), el primer lugar que revisamos es el Programador de Acciones (Action Scheduler). Es el corazón que bombea las tareas en segundo plano de tu tienda.
Lo que encontramos fue una arteria completamente tapada:
(Pie de foto: Un desastre digital: más de 2.800 tareas fallidas y 650 vencidas, con el sistema gritando que ha alcanzado el “máximo de colas simultáneas”. El sitio estaba técnicamente infartado.)
El sistema estaba tan ocupado intentando procesar basura antigua que no tenía recursos para atender a los clientes nuevos.
Paso 2: Identificando la “Basura”
Teníamos que saber qué era lo que estaba atascando la tubería. Al revisar los detalles de las tareas fallidas, encontramos un patrón claro.
(Pie de foto: El culpable recurrente. Miles de intentos fallidos de “webhooks” tratando de comunicarse con servicios externos.)
Estos “webhooks” son los mensajeros que le avisan a sistemas externos (como tu CRM o herramientas de email marketing) que algo pasó en la tienda.
Al revisar la configuración de WooCommerce, confirmamos que la tienda tenía activos múltiples avisos hacia Avify y Klaviyo para cada movimiento de productos y pedidos.
(Pie de foto: La lista de webhooks activos. Cada vez que se crea o actualiza un producto, la tienda intenta avisar a Avify y Klaviyo.)
El problema no era Avify per se. El problema era que, por alguna razón, la comunicación falló hace días, y la tienda se quedó intentando re-enviar esos mensajes miles de veces, sin éxito.
Paso 3: La limpieza quirúrgica
Con el diagnóstico claro, tocaba operar. No podíamos simplemente “borrar todo”, porque eliminaríamos tareas de mantenimiento vitales de WooCommerce. Teníamos que filtrar.
Usamos el buscador para encontrar solo las tareas relacionadas con “webhooks”.
(Pie de foto: Filtrando la basura. Al buscar “webhook”, aislamos los miles de intentos fallidos de sincronización de los IDs 6 y 7.)
Identificamos que los IDs 6 y 7 correspondían específicamente a las notificaciones de productos de Avify.
(Pie de foto: Confirmando que el ID 6 es el webhook de “Product Updated” de Avify.)
Procedimos a eliminar esas miles de tareas atascadas. Fue como quitarle una mochila de 50 kilos de encima al servidor.
Paso 4: Encontrando la “Pistola Humeante” (La Causa Raíz)
Limpiamos el desastre, pero, ¿por qué ocurrió? Si no arreglábamos la causa, volvería a pasar en 24 horas.
Un e-commerce saludable necesita un “motor” que ejecute tareas automáticamente cada pocos minutos. En WordPress, esto se llama Cron Job.
Primero, verificamos que el Cron nativo de WordPress (que es perezoso e ineficiente para tiendas grandes) estuviera desactivado en el archivo wp-config.php. Esto es una buena práctica.
(Pie de foto: El archivo wp-config.php mostrando que el cron nativo de WP estaba correctamente desactivado.)
El problema es que, si apagas el motor nativo, tienes que encender uno en el servidor.
Fuimos al panel de control del hosting (SiteGround) y encontramos el problema real. El “motor de reemplazo” estaba mal configurado.
(Pie de foto: La causa del desastre. Un comando Cron mal escrito que intentaba entrar a un archivo como si fuera una carpeta, y programado para correr solo cada 30 minutos. Básicamente, el motor nunca encendía.)
La tienda había estado operando sin sistema automático durante semanas. Solo procesaba tareas cuando un humano entraba al panel de administración.
Paso 5: La solución definitiva (Automatización Real)
Arreglamos el comando usando una instrucción robusta (wget) y, lo más importante, configuramos la frecuencia al estándar de oro del e-commerce: cada 5 minutos.
(Pie de foto: La configuración correcta. Usando el formato */5 * * * *, aseguramos que el servidor revise y ejecute tareas pendientes cada 5 minutos exactos, 24/7.)
El Giro Inesperado: Cuando la cura casi mata al paciente
Aquí es donde la experiencia cuenta. Una vez que arreglamos el motor y destapamos la cañería, el sitio… se cayó. El uso de CPU se disparó al 100%.
¿Por qué? No fue Avify.
Al reactivar el sistema y empezar a mover productos, el plugin de Facebook for WooCommerce detectó actividad y entró en pánico, intentando re-escanear todo el catálogo de la tienda simultáneamente.
Los registros del servidor mostraron que Facebook estaba golpeando la puerta de la tienda (admin-ajax.php) más de 10.000 veces en pocos minutos, colapsando el servidor.
La solución final: Tuvimos que desactivar temporalmente el plugin de Facebook y aplicar reglas de bloqueo en el servidor (.htaccess) para detener el ataque de los bots de Meta y dejar que el servidor respirara.
Conclusión
Lo que parecía un problema simple de “mi CRM no conecta” resultó ser una tormenta perfecta de:
- Basura acumulada en la base de datos.
- Un sistema de automatización (Cron) roto en el servidor.
- Un plugin de terceros (Facebook) reaccionando agresivamente a los arreglos.
En PyMES Modernas, no solo hacemos sitios bonitos. Entendemos la “fontanería” compleja que mantiene vivo tu negocio digital. Si tu tienda WooCommerce se siente lenta o inestable, no esperes a que el infarto sea total. Contáctanos para una revisión técnica profunda.
