Ir al contenido 
cronjobs de WordPress fallan bajo carga cuando las peticiones de páginas bloquean el programador interno, las cachés interceptan las peticiones o los límites de alojamiento limitan las tareas largas. Muestro las causas, consecuencias y soluciones concretas para garantizar que tareas como actualizaciones, copias de seguridad y publicaciones programadas se ejecuten de forma fiable.
Puntos centrales
Para empezar, resumiré los aspectos más importantes de forma breve y clara antes de entrar en más detalles y explicar pasos concretos que yo utilizo de forma productiva. Identificación del problema y Causas son el centro de atención aquí.
- MecánicaWP-Cron se activa en las peticiones de página en lugar de a través del cron del sistema.
- CargaEl alto tráfico y la „carga de wordpress cron“ generan timeouts.
- Almacenamiento en cachéLa caché CDN completa detiene la ejecución de cron.
- LímitesLos tiempos de espera de PHP y los presupuestos de recursos cancelan las tareas.
- soluciónCron del servidor, intervalos de limpieza, registro y ajuste.
WP-Cron explicado brevemente: Llamada a página en lugar de servicio del sistema
Empiezo con el Idea básicaWordPress comprueba si las tareas programadas están pendientes en cada petición de página y las lanza a través de una petición HTTP interna a wp-cron.php. Este enfoque compensa la falta de acceso a los crones reales del servidor, pero crea una dependencia de la aplicación Tráfico. Si una página apenas llega a los visitantes, las tareas se ejecutan tarde o no se ejecutan en absoluto. Si una CDN sirve todas las peticiones desde la caché, PHP no se carga y WP-Cron permanece en silencio. Esto explica por qué las publicaciones programadas, los trabajos de correo electrónico o las copias de seguridad parecen poco fiables en algunas instalaciones. Cuantos más plugins registren tareas adicionales, más densa se vuelve la cola y más vulnerable se vuelve la ejecución.
Por qué se derrumba Last Cronjobs
Si el flujo de visitantes aumenta, también lo hacen las comprobaciones de cron y, por tanto, el Carga del servidor. Un mayor número de peticiones concurrentes compiten por los PHP workers, la E/S y la base de datos, provocando que las llamadas a cron entren en timeouts. Las latencias se acumulan, las tareas se bloquean entre sí, y las tareas largas salen de la ventana de tiempo. Constantemente trato esto en configuraciones productivas, como WP-Cron en sitios de producción suele ser el desencadenante de tiempos de respuesta lentos. Cuando la carga es alta, las ralentizaciones se correlacionan directamente con el uso excesivo de activadores cron. Además, las tareas mal escritas agravan la situación porque inician exploraciones de bases de datos que consumen aún más recursos.
Límites de alojamiento y sus consecuencias
Muchos hosters utilizan un Tiempo de espera PHP de 30-60 segundos; si una tarea supera esta marca, el sistema la termina de forma contundente. Esto afecta a los trabajos de migración, las grandes exportaciones, el procesamiento de imágenes o los correos electrónicos masivos. Memory_limit, los límites de proceso y los límites de tasa para loopbacks HTTP tienen un efecto similar. Si además hay poco tráfico, los eventos debidos se acumulan y se ejecutan tarde o no se ejecutan en absoluto. Por lo tanto, primero compruebo los límites y los registros antes de modificar la aplicación. Esto me permite reconocer si el entorno está causando cuellos de botella o si las tareas individuales son ineficientes.
Comprobación rápida: causas, síntomas, soluciones
El siguiente resumen me ayuda a separar los patrones de error de forma estructurada y a actuar con determinación en lugar de experimentar al azar. Cada línea muestra un Causa, a visible Síntoma y una medida inmediata.
| Causa | Síntoma típico | medida inmediata |
|---|---|---|
| CDN/Reversed Proxy sirve 100% desde caché | Las contribuciones previstas aparecen con retraso | Desacoplar WP-Cron, establecer cron servidor real |
| Tiempo de espera PHP (30-60 s) | Copias de seguridad/exportaciones canceladas | Aumentar el tiempo de espera, dividir la tarea en lotes más pequeños |
| Demasiados eventos cron | Latencia notable con picos de tráfico | Estirar intervalos, eliminar eventos innecesarios |
| Consultas SQL ineficaces | La utilización de la base de datos aumenta a pasos agigantados | Fijación de índices, reducción de SELECT, almacenamiento en caché |
| Sitio web con poco tráfico | Horas de retraso | Ejecute el cron del sistema cada 15-60 minutos |
Complemento la comprobación con métricas reales de registros y monitorización para verificar los supuestos y analizar la Causa pruebas claras. La tabla no sustituye a una medición, la canaliza. Sólo cuando sé si el tiempo de espera, la caché o la base de datos son limitantes, tomo las medidas adecuadas. Después hago pruebas repetidas y compruebo si hay efectos posteriores. De este modo, minimizo el esfuerzo y resuelvo el problema de forma sostenible.
Buenas prácticas: De WP-Cron a Server-Cron
Primero desactivo el activador basado en página con DISABLE_WP_CRON en wp-config.php: define(‚DISABLE_WP_CRON‘, true);. Luego configuro un cron de sistema real que llama a wp-cron.php cíclicamente (por ejemplo, mediante curl cada 5 minutos para tráfico alto, cada hora para tráfico bajo). Esto me permite desacoplar las ejecuciones del flujo de visitantes y suavizar el Carga. Al mismo tiempo, limito las llamadas simultáneas para que no se produzcan tormentas cron. Si espero picos, aumento los PHP workers y ajusto los tiempos de espera. Especialmente con tráfico fluctuante, reduzco Carga desigual de la CPU y evitar reacciones en cadena.
Intervalos, diseño de tareas y base de datos
Compruebo cada evento para su Intervalo y estiro las frecuencias siempre que sea justificable. En lugar de cada minuto, escaneo cada hora o cada día si la tarea no requiere un valor en tiempo real. Divido las tareas largas en pequeños lotes que se ejecutan con seguridad dentro del tiempo de espera de PHP. Cuando accedo a bases de datos, establezco índices, reduzco columnas y me abstengo de realizar exploraciones completas. Almaceno en caché los datos frecuentes para interceptar las repeticiones y minimizar el Base de datos del trabajo innecesario. Esto reduce los tiempos de ejecución y las ejecuciones de cron siguen siendo calculables.
El diagnóstico en la práctica: crear visibilidad
Antes de reconstruir, quiero tener fiable Datos de diagnóstico. Empiezo con la visualización de la salud del sitio de WordPress y activo el registro (WP_DEBUG_LOG) para hacer visibles los errores de PHP durante las llamadas cron. A continuación, enumero los eventos vencidos y programados y sus tiempos de ejecución. En flujos de trabajo productivos, utilizo pasos repetibles para esto:
- Activar eventos debidos a través de WP-CLI: wp cron event run -due-now
- Lista de eventos programados: wp cron lista de eventos
- Establezca sus propios puntos de medición: Registre la hora de inicio y fin de la tarea, incluidos los picos de memoria
- Compruebe la página de la base de datos: Identificar los SELECT largos y añadir los índices necesarios
Si Site Health muestra „Ejecución retrasada de cron“, analizo los registros de acceso en wp-cron.php, los códigos de respuesta y la duración. 429/503 indican límites de velocidad o recursos, 401/403 indican bloqueo por auth, firewall o WAF. Compruebo si las peticiones loopback están permitidas internamente y si el nombre del host se resuelve correctamente. También miro la opción „cron“ de wp_options para evaluar el tamaño y la edad de la cola e identificar los ganchos de función que fallan repetidamente.
Configuración robusta del cron del servidor: HTTP, WP-CLI y bloqueo
Para entornos productivos, prefiero un Servidor cron vía WP-CLI sobre una llamada HTTP pura, porque inicio PHP directamente y dependo menos del servidor web/proxy. Variantes ejemplares que se han probado:
- Variable HTTP, con presupuesto de tiempo y parada: curl -sS https://domain.tld/wp-cron.php?doing_wp_cron=1 -max-time 55 -connect-timeout 5 >/dev/null
- WP-CLI directamente: cd /ruta/a/instalación && /usr/bin/wp cron event run -due-now -quiet
- Evitar solapamientos: flock -n /tmp/wp-cron.lock -c „/usr/bin/wp cron event run -due-now -quiet“
- Aumentar los recursos de forma selectiva: php -d memory_limit=512M -d max_execution_time=300 wp-cli.phar cron event run -due-now
Utilizo flock para evitar arranques paralelos, que de otro modo darían lugar a ejecuciones duplicadas y accesos a la base de datos en competencia. Con varias instancias (por ejemplo, Azul/Verde, Contenedor), sólo permito que un host ejecute el cron y lo desactivo en los demás. Así evito condiciones de carrera en la cola.
Loopbacks, auth y cortafuegos: bloqueos típicos
Si los cronjobs se quedan colgados en „pendiente“, el cronjob interno suele bloquearse. Loopback. Compruebo si Basic-Auth, las restricciones de IP o un WAF impiden las peticiones a wp-cron.php. En configuraciones seguras, excluyo wp-cron.php de la autenticación o permito loopbacks como excepción. Si las llamadas HTTP externas están restringidas, me aseguro de que mi propio dominio no esté en la lista de bloqueo. ALTERNATE_WP_CRON puede ayudar a corto plazo, pero sólo lo uso temporalmente y lo elimino de nuevo tan pronto como un cron de servidor limpio está activo.
Solapamientos e idempotencia: tareas seguras
Muchos problemas surgen debido a Ejecuciones simultáneas de la misma tarea. Por tanto, instalo bloqueos de tareas (por ejemplo, mediante transient/option), compruebo si una ejecución ya está activa antes de iniciarla y finalizo la segunda llamada antes de tiempo. Al mismo tiempo, hago que las tareas sean idempotentes: si un paso se inicia dos veces, no se duplican correos electrónicos, archivos o entradas en la base de datos. Para los trabajos por lotes, guardo los offsets/marcadores para controlar las continuaciones limpiamente e interceptar las repeticiones. Esto reduce los daños consecuentes si una ejecución cron se detiene inesperadamente y se reinicia más tarde.
Escalado: multiservidor, contenedor y multisitio
En entornos distribuidos opero exactamente uno Cron runner. Este puede ser un contenedor trabajador separado o un nodo fijo que dispara todos los eventos debidos vía WP-CLI. Los sistemas de archivos compartidos o las cachés distribuidas ayudan a mantener los estados y bloqueos consistentes entre instancias. En configuraciones multisitio, compruebo si Cron está correctamente programado para cada red subsitio y si los eventos de red no están inundando la cola global de forma incontrolada. También me aseguro de que las zonas horarias por sitio son correctas para que las publicaciones y las ventanas de tiempo sean correctas.
Horarios y husos horarios: evite el „horario perdido“.
Un factor subestimado son Husos horarios y el cambio de hora en verano. WordPress programa las entradas en la zona horaria del sitio, mientras que los servidores suelen funcionar en UTC. Sincronizo ambos, compruebo la configuración de la zona horaria de los despliegues y tengo en cuenta los cambios de hora en el plan editorial. Si se produce un „Missed schedule“, compruebo si el cronqueue está sobrecargado, si los ganchos de publicación están fallando o si la hora del servidor se está desviando. Un „wp cron event run -due-now“ posterior descarga la cola mientras arreglo la causa real (caché, tiempo de espera, zona horaria incorrecta).
Desarrollo, puesta en marcha y despliegue
En los entornos de ensayo, desactivo las tareas productivas (correos electrónicos, exportaciones, webhooks) para que no se desencadenen acciones no deseadas. Establezco DISABLE_WP_CRON en true y ejecuto mi propio cron de prueba con intervalos largos. Antes de la puesta en marcha, vacío la cola, ejecuto las tareas críticas una vez manualmente y controlo los registros de cerca. Después de los despliegues, una ejecución „due-now“ específica activa los nuevos ganchos antes de que las cachés vuelvan a ser agresivas. Esto evita sorpresas y mantiene la fase de introducción tranquila.
Tratamiento de errores, retroceso y repeticiones
Los fracasos ocurren. Planifico para ellos Reintentos con backoff: sólo se vuelve a intentar después de un breve periodo de tiempo, luego con una distancia cada vez mayor. Documento los pasos fallidos con códigos claros y contexto (entrada, duración, memoria, SQL, código HTTP). Después de N intentos fallidos, marco el evento como „atascado“ y me informo mediante una alerta. Esta separación evita bucles interminables y me da tiempo para rectificar la causa real sin atascar la cola.
Herramientas: WP Crontrol y Action Scheduler
Para el diario Controlar Utilizo WP Crontrol para ver, pausar o reprogramar eventos directamente en WordPress. Lo utilizo para reconocer ganchos colgantes, entradas duplicadas o intervalos incorrectos. Para procesos grandes, utilizo Action Scheduler, que divide las tareas en pequeñas acciones y las registra de forma limpia. Si una acción falla, la reinicio de forma selectiva sin poner en peligro toda la cadena. Esto minimiza los picos porque no estoy empujando a través de un monolito, sino más bien Subtareas tácticamente. De este modo, los despliegues y las ventanas de mantenimiento son predecibles.
Alojamiento compartido, caché y CDN
En entornos compartidos, las llamadas a cron chocan rápidamente con Límites, que no controlo directamente. Si la CDN y la caché de página completa surten efecto, ni una sola petición de página activa WP-Cron. Soluciono esto con un cron del sistema y me aseguro de que las peticiones loopback son accesibles. Cuando el cron no se dispara de forma fiable, compruebo las políticas de red, la autenticación básica y los cortafuegos. Una prueba con una llamada curl directa muestra si las peticiones están llegando técnicamente. Para más información y alternativas, consulte Tareas programadas en alojamiento compartido, porque allí se describen de forma compacta los escollos típicos.
Control y mantenimiento en la vida cotidiana
Guardo el Sitio-Salud-Esto se debe a que WordPress informa visiblemente de retrasos en las ejecuciones de cron. También escribo registros para analizar estadísticamente la duración, los errores y las repeticiones. Así se descubren anomalías que, de otro modo, pasarían desapercibidas en el día a día. Elimino o restablezco los eventos obsoletos o que fallan permanentemente para mantener la cola en orden. Las alertas por correo electrónico o Slack me informan si un trabajo falla varias veces. Esto me permite intervenir antes de que las consecuencias, como actualizaciones perdidas o correos electrónicos no enviados, causen daños.
Conclusión: mi enfoque en pocas palabras
Primero desacoplaré Cron de las llamadas a la página, estableceré un Servidor cron y compruebo la accesibilidad mediante curl. A continuación, optimizo los intervalos, divido las tareas largas en lotes y reduzco la carga de la base de datos. Configuro el registro, miro las rutas de error y ajusto los límites para que ninguna tarea se bloquee en el tiempo límite. Si es necesario, utilizo Action Scheduler porque divide de forma fiable los procesos largos en partes controlables. Luego mido el efecto y racionalizo la lista cron hasta que la cola queda limpia. De este modo, las tareas programadas se ejecutan de forma fiable, aunque el Carga subidas o cachés funcionan de forma agresiva.
