Cuando una entrada programada no se publica a la hora esperada, el fallo puede estar en cuatro capas distintas: la hora guardada por WordPress, el evento de publicación programado, el mecanismo que activa WP-Cron o la ejecución del propio callback. Separar estas capas evita soluciones al azar, como cambiar la zona horaria, instalar otro plugin de cron o desactivar WP-Cron antes de confirmar la causa.
Qué ocurre cuando se programa una entrada
WordPress usa WP-Cron para tareas basadas en tiempo, incluida la publicación de entradas programadas. La documentación oficial explica que WP-Cron revisa las tareas pendientes cuando el sitio recibe cargas de página, en lugar de funcionar de forma continua como un servicio del sistema operativo. Por eso, un sitio con poco tráfico puede ejecutar una tarea después de la hora prevista. Consulta la documentación de WP-Cron.
Cuando una entrada tiene estado futuro, el núcleo de WordPress programa el hook publish_future_post. En el momento de la ejecución, WordPress confirma que la entrada todavía tiene estado future y la publica. Este comportamiento está documentado en check_and_publish_future_post().
1. Confirma primero la zona horaria y la hora realmente guardada
Antes de culpar al cron, abre Ajustes > Generales y revisa la zona horaria del sitio. Esta configuración controla cómo WordPress calcula y muestra fechas y horas. Después de guardar, la pantalla muestra UTC y hora local, lo que ayuda a detectar un desfase accidental. Consulta la documentación de Ajustes Generales.
- Confirma que la entrada siga programada y que la fecha mostrada sea la deseada.
- Compara la hora local que muestra WordPress con la hora esperada por el editor.
- Si la hora guardada es incorrecta, corrige la programación antes de cambiar el cron.
Un error de zona horaria puede hacer que una entrada parezca retrasada aunque el evento se haya programado para otro instante. Si fecha, hora y estado son correctos, continúa con el mecanismo de ejecución.
2. Revisa Salud del sitio y los loopbacks
Abre Herramientas > Salud del sitio. WordPress informa cuando el sitio no puede completar una solicitud loopback. Los loopbacks son peticiones que WordPress hace a su propio sitio y se usan para iniciar eventos programados. La documentación oficial sobre loopbacks menciona expresamente las entradas programadas entre los casos afectados.
Si falla el loopback, investiga primero conflictos de plugins o tema y después reglas del servidor, firewall, DNS, SSL o autenticación HTTP. En producción, es preferible reproducir el problema en staging o usar una ventana de mantenimiento antes de desactivar componentes.
3. Averigua si WP-Cron fue desactivado
Busca en wp-config.php la constante DISABLE_WP_CRON. Si está definida como true, WordPress deja de depender de las visitas para activar WP-Cron. Esto es correcto solo cuando otro mecanismo fiable está llamando al sistema cron de WordPress.
Un error frecuente es invertir el orden seguro: desactivar WP-Cron y solo después intentar configurar un programador externo. Si la tarea del servidor no existe, apunta a una URL incorrecta o está bloqueada, las entradas futuras pueden quedarse pendientes.
4. Con WP-CLI, confirma que cron puede iniciarse y que el evento existe
Si el alojamiento ofrece SSH y WP-CLI, hay dos comprobaciones útiles. wp cron test prueba el sistema de activación de WP-Cron. Su documentación indica que el comando comprueba DISABLE_WP_CRON, avisa sobre ALTERNATE_WP_CRON e intenta iniciar cron por HTTP. Consulta wp cron test.
Para inspeccionar la cola sin cambiar la programación, usa:
wp cron event list --hook=publish_future_post --fields=hook,next_run_gmt,next_run_relative
El comando de listado está documentado en wp cron event list. Si aparece el hook de publicación futura y está vencido, la programación existe y la investigación debe centrarse en la activación o la ejecución. Si no aparece para una entrada que debería estar programada, revisa el estado de la entrada y el proceso que creó la programación.
Atención: los comandos que prueban o ejecutan cron pueden activar tareas vencidas de plugins, correo, mantenimiento o integraciones. No supongas que una prueba de ejecución es solo lectura.
5. Separa los fallos de activación de los fallos de ejecución
| Señal | Interpretación probable | Siguiente comprobación |
|---|---|---|
| El evento futuro no existe | La entrada no se programó como se esperaba o el evento fue eliminado | Estado de la entrada, fecha y código o plugin que programa |
| El evento existe y está vencido | WP-Cron no fue activado o no pudo iniciarse | Loopback, DISABLE_WP_CRON, cron externo y bloqueos HTTP |
| Cron se inicia, pero la entrada no se publica | El callback puede estar fallando durante la ejecución | Logs PHP, conflictos y errores fatales |
| Solo falla en periodos sin visitas | La activación por tráfico puede ser insuficiente | Cron del servidor para una activación más predecible |
6. Cuándo usar el cron del servidor
Para sitios que necesitan horarios más previsibles, la documentación de WordPress recomienda usar el programador del sistema para llamar a wp-cron.php en los intervalos definidos por la operación. Después de confirmar que ese disparo externo funciona, WP-Cron activado por visitas puede deshabilitarse con define( 'DISABLE_WP_CRON', true );. Consulta Hooking WP-Cron Into the System Task Scheduler.
En paneles de alojamiento esta función puede llamarse Cron Jobs, Scheduled Tasks o de forma similar. El nombre cambia, pero el objetivo es el mismo: ejecutar periódicamente una llamada que inicia la cola de WordPress. No lo confundas con crear una tarea del servidor para cada entrada.
Orden seguro de migración:
- Crea la tarea externa sin desactivar WP-Cron.
- Confirma que realmente se ejecuta en el servidor y procesa eventos vencidos.
- Supervisa al menos un ciclo de programación compatible con la frecuencia elegida.
- Solo entonces define DISABLE_WP_CRON como true si existe un motivo para evitar la activación por visitas.
7. Si cron se activa, busca errores de ejecución
Cuando el evento existe y el mecanismo cron está activo, pero la publicación sigue fallando, revisa los logs del servidor y, en un entorno de prueba, las herramientas de depuración de WordPress. La documentación de Debugging in WordPress explica WP_DEBUG y WP_DEBUG_LOG y recomienda staging o una copia de seguridad antes de hacer cambios.
En producción, no dejes mensajes de depuración visibles en pantalla. Los logs pueden contener rutas, datos de peticiones y otra información sensible. Activa el diagnóstico solo durante el tiempo necesario, recoge el error, corrige la causa y restaura la configuración normal.
WP-Cron o cron del servidor: qué cambia
| Aspecto | WP-Cron activado por visitas | Cron del servidor llamando a WordPress |
|---|---|---|
| Activación | Depende de una oportunidad creada por una carga de página | Depende del programador configurado en el servidor |
| Horario | Puede retrasarse durante periodos sin tráfico | Es más predecible cuando la tarea externa funciona |
| Configuración | Comportamiento predeterminado de WordPress | Requiere acceso al panel del alojamiento, SSH o soporte del proveedor |
| Riesgo operativo | Los loopbacks y las restricciones HTTP pueden impedir el inicio | Una tarea externa rota puede detener cron por completo si la activación interna también está deshabilitada |
Rollback: cómo volver al comportamiento predeterminado
Si la migración a cron externo causa problemas, restaura la activación predeterminada eliminando la línea que define DISABLE_WP_CRON como true o cambiando el valor a false. Después confirma que el sitio puede realizar loopbacks y que aparecen nuevos eventos en la cola.
No elimines eventos cron en masa como primer intento. WordPress y los plugins comparten la misma cola para muchas rutinas. Primero identifica el hook afectado y la causa del retraso.
Flujo de diagnóstico en orden
- Confirma estado, fecha, hora y zona horaria de la entrada.
- Abre Salud del sitio y busca un fallo de loopback.
- Comprueba si DISABLE_WP_CRON está activo.
- Si tienes WP-CLI, prueba el mecanismo y lista publish_future_post.
- Si el evento está vencido, corrige la ruta de activación.
- Si cron se está activando, revisa los logs para detectar errores de ejecución.
- Si necesitas un horario más predecible, configura primero el cron externo y solo después considera desactivar la activación por visitas.
- Si el cambio empeora el escenario, haz rollback y vuelve al comportamiento predeterminado de WP-Cron.
Esta secuencia reduce el riesgo de confundir un desfase de zona horaria, poco tráfico, fallo de loopback, cron externo roto y un error PHP durante la publicación.
