La entrada debía publicarse antes del desayuno. A media mañana sigue pendiente, aunque la fecha y la hora parecen correctas. Cambiarla varias veces rara vez aclara el problema. Conviene separar dos preguntas: si la tarea quedó bien programada y si el sistema tuvo una oportunidad de ejecutarla.
En su funcionamiento habitual, WordPress revisa las tareas pendientes de WP-Cron durante las solicitudes que ejecutan WordPress. No vigila el reloj de manera continua, y una página servida íntegramente por una caché anterior a WordPress no ejecuta por sí sola esa comprobación. Por eso, en un sitio con pocas visitas puede haber una demora entre la hora prevista y la ejecución. Un programador del servidor configurado por intervalos funciona de otra manera.
Localiza dónde se detuvo el trabajo
Empieza por una tarea que se haya retrasado. Anota la hora esperada, la zona horaria configurada en el sitio y el momento en que detectaste la demora. Comprueba si también llegaron tarde otras tareas. Que falle únicamente la función de un plugin ofrece una pista distinta de encontrar varias tareas independientes vencidas al mismo tiempo.
Una publicación que casi no recibe visitas durante la noche puede tener un caso claro para investigar con su entrada matutina. En una tienda con tráfico constante, atribuir todo a la falta de visitas sin revisar errores resulta menos convincente. Una excepción del plugin, una solicitud fallida o una restricción del alojamiento podrían necesitar su propia revisión. El síntoma no identifica por sí solo la causa.
Leer el diagrama como texto
- Llega la hora del evento: La hora guardada ya pasó, pero eso no ejecuta la tarea por sí solo.
- Se ejecuta WordPress: Una solicitud que llega a WordPress puede activar la revisión de tareas pendientes.
- Se intenta realizar la tarea: Errores, solicitudes bloqueadas o restricciones todavía pueden interrumpirla.
- Comprueba el resultado: Revisa la publicación o copia terminada, no solo una solicitud registrada.
Confirma el programador sustituto antes de desactivar el disparador actual.
Acuerda cómo se activará la programación
WordPress documenta una alternativa: activar su script de cron desde un programador del sistema y después deshabilitar la activación automática por visitas. Coordina ese cambio con el alojamiento. No retires el mecanismo existente antes de configurar y comprobar el nuevo; una migración incompleta puede dejar trabajo pendiente.
Explica al proveedor una necesidad concreta, en lugar de pedir el intervalo más corto posible. Indica qué tarea importa, cuánto retraso sería aceptable y quién comprueba el resultado. Una rutina editorial diaria y un proceso comercial sensible al tiempo merecen conversaciones distintas. No copies comandos de otra cuenta, donde podrían cambiar las rutas, los permisos y las herramientas disponibles.
Después del ajuste, comprueba el resultado del trabajo. Ver una solicitud en un registro no demuestra que una copia de seguridad terminara o que la entrada programada esté pública. Utiliza una tarea de prueba sin consecuencias, revisa su resultado y observa la siguiente ejecución habitual. Mantén privados los registros que incluyan datos de cuentas o material sin publicar.
Deja anotado quién mantiene la programación y dónde se configura. Incluye esa información cuando cambies de alojamiento. Una solución fiable debe seguir funcionando durante una noche sin visitas, un cambio de responsable y una migración, sin depender de que alguien recuerde un ajuste que nunca quedó documentado.
