WP-Cron no ejecuta tareas: cómo comprobar programación y ejecución
Distingue una tarea inexistente, vencida y ejecutada con error. Configurar otro disparador no repara por sí solo el trabajo que falla dentro de la aplicación.
Si una tarea programada de WordPress no produce su resultado, comprueba si llegó a registrarse, si venció y si su ejecución falló. Crear otro cron del servidor puede ayudar a iniciar el trabajo con una frecuencia definida, pero no repara una función que termina con error ni crea un evento que falta.
Esta guía investiga ausencia o retraso de ejecución, no el rendimiento general del sitio. Si el síntoma principal es consumo alto, consulta qué revisar cuando WooCommerce consume demasiados recursos.
Identificar la tarea y su resultado esperado
Anota qué debería ocurrir, quién lo programa y cuándo se observó el último resultado válido. Distingue una publicación programada de una sincronización de una extensión: pueden utilizar recorridos diferentes.
La documentación de WordPress explica que WP-Cron comprueba tareas durante cargas de página y no funciona continuamente como un planificador del sistema. En instalaciones con otro mecanismo de disparo, hay que identificar ese mecanismo antes de aplicar una receta genérica.
Verificar que el evento exista
Pide al administrador que inspeccione los eventos del sitio y su próxima ejecución. WP-CLI ofrece herramientas para revisar cron, pero su uso requiere acceso autorizado y conocer el entorno de esa instalación.
Si el evento no está registrado, investiga qué componente debía programarlo y en qué condición. Si se registra repetidamente, revisa esa causa en vez de acumular más disparadores. La existencia de un evento tampoco demuestra que su función se complete.
Contrastar hora, intervalo y último resultado
Comprueba la referencia temporal que utiliza cada sistema al interpretar el horario. Una fecha mostrada en otro huso puede parecer un retraso que no existe. Registra la próxima ejecución y el momento real del resultado para distinguir expectativas de evidencia.
No concluyas que el trabajo funcionó porque cambió su fecha programada. Una ejecución puede avanzar la planificación y fallar después dentro de la operación. Busca su resultado específico y los registros que permita el componente responsable.
Revisar cómo se inicia el trabajo
Identifica si depende del mecanismo habitual de WordPress, de una llamada externa o del planificador del servidor. Comprueba configuración, permisos y registros del disparador. Si hay restricciones de acceso, no retires protecciones de toda la web para facilitar una única llamada.
Una respuesta HTTP satisfactoria del punto de entrada no certifica que todas las tareas pendientes hayan terminado. Del mismo modo, una tarea que no produce resultado puede tener un disparador correcto y un error posterior. Conserva ambas capas en el diagnóstico.
Investigar la función que se ejecuta
Correlaciona errores, dependencias externas y datos de entrada con el momento esperado. Como ejemplo hipotético, una importación puede comenzar puntualmente y detenerse porque el proveedor rechaza sus credenciales. Aumentar la frecuencia de cron solo repetirá el fallo.
En WooCommerce, algunas extensiones utilizan colas y mecanismos adicionales. No trates automáticamente cada acción pendiente como un evento directo de WP-Cron ni borres colas para simular que están resueltas. Puede haber pedidos, notificaciones o renovaciones todavía sin procesar.
Cuándo utilizar un planificador del servidor
WordPress documenta cómo coordinar WP-Cron con el planificador del sistema. Puede ser adecuado para disponer de un disparo independiente de las visitas, pero debe configurarse y verificarse antes de retirar el mecanismo anterior.
Acuerda usuario, entorno, frecuencia y tratamiento de ejecuciones simultáneas. No copies un intervalo universal sin conocer duración, criticidad y límites del trabajo. Configurar un disparador más frecuente no equivale a garantizar un plazo de finalización.
Recuperar pendientes sin repetir efectos
Antes de forzar tareas, identifica cuáles escriben datos, envían mensajes o crean operaciones externas. Prueba un caso controlado y acuerda cómo distinguir lo ya realizado de lo pendiente. Una ejecución parcial puede requerir reconciliación antes del reintento.
Conserva la causa, el cambio de configuración, las pruebas y el resultado siguiente. El mantenimiento WordPress, el soporte WooCommerce y la revisión de servidores Linux permiten distribuir responsabilidades entre aplicación y disparador sin confundirlos.