Cómo diagnosticar publicaciones programadas que fallan en WordPress antes de sustituir WP-Cron

Un artículo programado que aparece tarde no necesita automáticamente otro plugin de programación. Primero determina si WordPress tuvo oportunidad de ejecutar la tarea, si esta falló y si la publicación ya debía producirse según la zona horaria configurada. Son problemas diferentes y requieren reparaciones diferentes.

El manual de cron de WordPress explica que WP-Cron comprueba las tareas durante las cargas de página, en vez de funcionar continuamente como un programador del sistema. Por eso un sitio con pocas visitas aporta una pista importante. No demuestra que la falta de tráfico causara un retraso concreto, porque también hay que revisar la configuración y los fallos de ejecución.

Establece qué debería haber ocurrido

Registra la fecha y hora programadas, la zona horaria del sitio y el momento en que alguien detectó el retraso. El reloj del portátil de un colaborador no basta para demostrar la hora prevista por el sitio. Si los editores trabajan desde distintos países, acuerda qué reloj rige la publicación y muéstralo claramente en la lista editorial.

Después confirma que el artículo seguía programado, y no como borrador, pendiente de revisión o privado. Revisa el último cambio editorial y cualquier plugin del flujo de trabajo. Una entrada que espera aprobación no es un evento cron fallido. Conserva el estado previsto antes de publicarla manualmente, para que el arreglo provisional no borre información necesaria para el diagnóstico.

Piensa en un artículo hipotético programado para una mañana de fin de semana con poca actividad. Si aparece al llegar la primera visita posterior, la falta de activación se vuelve plausible. Si otras tareas se ejecutaron a tiempo y solo falló ese artículo, conviene centrar la investigación en la entrada o su función. Anota las explicaciones alternativas antes de instalar nada.

Inspecciona la cola antes de ejecutarla

La guía oficial de pruebas describe comandos de WP-CLI para listar y ejecutar eventos. El responsable técnico puede empezar con wp cron event list, que es de solo lectura, desde el entorno correcto. Identifica el hook pertinente, la hora programada y la recurrencia sin borrar ni ejecutar la cola.

No ejecutes todos los eventos pendientes como atajo general de diagnóstico. Según los plugins, las tareas pueden enviar correos, renovar accesos, sincronizar registros o realizar otras operaciones relevantes. Antes de ejecutar un evento concreto manualmente, identifica su función, comprueba si ya se ejecutó por otra vía y acuerda cómo verificarás el resultado.

Compara la cola con los registros de aplicación y alojamiento alrededor de la hora prevista. Busca errores vinculados a la acción, límites de recursos o solicitudes incompletas. Que una tarea aparezca en una lista demuestra que está programada, no que su función pueda terminar correctamente. Anota el error exacto en lugar de llamar problema de cron a cualquier fallo.

Revisa el activador y cualquier programador alternativo

Pregunta al alojamiento o al responsable si el sitio usa la activación normal por cargas de página o un programador externo. WordPress documenta la conexión de WP-Cron con un programador del sistema, incluida la desactivación del activador normal después de establecer la alternativa. Copiar solo el paso de desactivación puede dejar el sitio sin el reemplazo previsto.

Si existe una tarea externa, verifica la ruta o URL, el usuario de ejecución, el intervalo y los resultados recientes. Un programador configurado para una copia de pruebas no demuestra que producción esté cubierta. Del mismo modo, que un comando figure como iniciado no prueba que WordPress alcanzara el evento previsto. Pide pruebas de finalización en el entorno correcto.

Revisa si la autenticación, los controles de seguridad o las restricciones de red interfieren con el mecanismo concreto. No desactives todo el cortafuegos como primer experimento. El responsable puede aislar la solicitud y probar una excepción limitada cuando esté justificada. Mantén una vía de reversión y registra si la excepción cambia realmente el fallo observado.

Repara una capa y prueba una programación real

Cuando las pruebas respalden la falta de activación, acuerda un sistema de programación compatible con el alojamiento y adecuado a la carga. Si falla una función, repara el plugin o la integración responsable en vez de aumentar la frecuencia. Ejecutar más a menudo una tarea rota puede añadir carga sin publicar el artículo. Cada mecanismo requiere su solución.

Prueba con un artículo programado ordinario y de bajo riesgo en un entorno adecuado, y verifica tanto el resultado editorial como el registro de ejecución. Si pruebas en producción, el contenido debe ser apto para publicación y contar con la aprobación editorial habitual. No uses un artículo público falso solo para generar una señal visible de éxito.

Observa más de un ciclo, incluido un periodo con poca navegación. Comprueba que el mismo evento no se ejecute dos veces después del cambio. Guarda los valores anteriores y nuevos en el registro de mantenimiento, junto con la persona responsable de la siguiente comprobación. La reparación debe seguir funcionando cuando ya no esté quien la realizó.

Utiliza el proceso de pruebas y reversión si el cambio afecta a plugins o configuración. Añade una comprobación breve de publicación programada a la rutina de mantenimiento. El resultado útil es una ruta conocida desde la programación editorial hasta la ejecución correcta, con pruebas suficientes para diagnosticar rápidamente el siguiente retraso.