Cómo funciona WP-Cron en WordPress

WP-Cron es el programador integrado de WordPress. Ejecuta trabajo como publicar entradas programadas, comprobar actualizaciones y tareas recurrentes de plugins.

• Publicar entradas programadas
• Comprobar actualizaciones de plugins y temas
• Enviar correos programados (newsletters, resúmenes, notificaciones)
• Ejecutar rutinas de copia de seguridad y mantenimiento
• Limpiar datos temporales y elementos caducados
• Ejecutar tareas de seguridad como análisis o tareas de mantenimiento

El detalle importante: WP-Cron no es un demonio cron real del servidor. Es un «pseudo-cron» que depende del tráfico del sitio web para disparar la comprobación. Ese diseño hace WordPress portable (funciona en casi cualquier hosting), pero también explica por qué las tareas programadas pueden ejecutarse tarde o provocar problemas de rendimiento.

¿Qué es WP-Cron?

En un servidor Linux típico, un cron real se ejecuta a horas o intervalos fijos, haya visitas o no. Por eso el cron del servidor es predecible: se ejecuta porque el servidor lo ordena.

WP-Cron funciona distinto. WordPress comprueba las tareas pendientes durante las cargas normales de página y luego dispara el procesamiento de cron si algo está programado. En la práctica, ocurre así:

• Un visitante (o bot) pide cualquier página de tu sitio
• WordPress carga y comprueba la programación (guardada en la base de datos)
• Si hay eventos pendientes, WordPress dispara el procesamiento de cron

Sin tráfico no hay disparador. Por eso los sitios con poco tráfico a veces pierden horarios. Y por eso los sitios con mucho tráfico pueden disparar cron con demasiada frecuencia salvo que lo controles.

Cómo WP-Cron ejecuta tareas entre bastidores

Tus eventos programados se guardan en la base de datos de WordPress. Cuando WordPress detecta que un evento está pendiente, llama a wp-cron.php para procesar la cola.

Una razón por la que WordPress llama a wp-cron.php mediante una petición HTTP es la experiencia de usuario: algunas tareas de cron pueden tardar. Si WordPress intentara ejecutarlo todo dentro de la misma petición de página, los visitantes podrían esperar una carga lenta. En su lugar, WordPress intenta «generar» cron como petición en segundo plano para que el visitante reciba su página mientras el trabajo de cron ocurre aparte.

El procesamiento de cron continúa hasta que terminan todos los trabajos pendientes o hasta que los límites de ejecución del servidor (timeouts, límites de workers, etc.) lo cortan. Por eso la calidad del hosting y la configuración del servidor afectan directamente a la fiabilidad de cron.

Qué funciones se usan para programar trabajos

Los desarrolladores programan tareas con la API Cron de WordPress. Las funciones más habituales son:

• wp_schedule_event() para eventos recurrentes
• wp_schedule_single_event() para eventos puntuales
• wp_next_scheduled() para comprobar si algo ya está programado
• wp_clear_scheduled_hook() para eliminar eventos programados

WordPress incluye intervalos de recurrencia predeterminados como hourly, twicedaily, daily y weekly. Los plugins y el código personalizado también pueden añadir intervalos extra con el filtro cron_schedules.

Por qué WP-Cron puede ser poco fiable

El diseño basado en tráfico funciona en casi cualquier hosting, pero también crea los problemas de programación más habituales.

1. Sitios con poco tráfico: las tareas se ejecutan tarde

Si tu sitio no recibe visitas cerca de la hora en que una tarea debe ejecutarse, puede no ejecutarse hasta la siguiente visita. Eso puede provocar molestias reales como entradas programadas que se publican tarde, correos en cola que salen tarde o trabajos de mantenimiento que no corren a tiempo.

• Las entradas programadas se publican «cuando alguien visite después»
• Las copias de seguridad y limpiezas pueden retrasarse
• Los análisis de seguridad pueden posponerse y crear puntos ciegos

2. Sitios con mucho tráfico: demasiados lanzamientos de cron

En sitios concurridos, las comprobaciones de WP-Cron pueden ocurrir con frecuencia. WordPress usa un bloqueo para evitar que cron se lance repetidamente al mismo tiempo (guarda un bloqueo en el transiente doing_cron), pero la alta concurrencia puede seguir generando carga.

Los síntomas típicos son:

• Mayor uso de CPU de lo esperado
• Varios workers PHP ocupados en trabajo en segundo plano
• Picos de rendimiento aunque el tráfico del frontend parezca «normal»

Algunos hostings también limitan las peticiones loopback salientes (tu sitio llamándose a sí mismo), y eso puede romper el lanzamiento de cron de formas sutiles.

3. Tareas largas: timeouts y finalización parcial

No todos los trabajos de cron son iguales. Algunos son rápidos (como comprobar una opción) y otros pesados (como analizar archivos, generar informes o importar datasets grandes). Si un callback de cron tarda demasiado, puede chocar con límites de tiempo de PHP, memoria o workers. El resultado puede ser un trabajo que nunca termina limpiamente, o trabajos que se reinician una y otra vez y generan carga.

Cómo saber si WP-Cron funciona

Una prueba básica rápida es visitar:

https://tudominio.com/wp-cron.php

Suele verse una página en blanco, lo que simplemente significa que el endpoint es accesible. No garantiza que todo esté perfecto, pero confirma que el archivo se puede ejecutar.

Si quieres una vista más clara de lo programado y lo que se ejecuta, un plugin como WP Crontrol puede mostrarte eventos programados, próximas ejecuciones y qué hooks están en cola. Suele ser la forma más rápida de descubrir un plugin que programa demasiado agresivamente o falla repetidamente.

Enfoque recomendado: desactivar WP-Cron y usar un cron real del servidor

Para muchos sitios en producción, la solución más estable es:

1. Desactivar el comportamiento automático al cargar páginas
2. Disparar cron con un cron real del servidor en un horario fijo

Eso te da horarios predecibles y evita comprobaciones de cron en cada carga de página.

Paso 1: Desactivar el lanzamiento automático de WP-Cron

Edita wp-config.php y añade esta línea justo encima del comentario «That’s all, stop editing»:

define( 'DISABLE_WP_CRON', true );

Nota importante: esto no «apaga cron para siempre». Solo impide que WordPress lance cron automáticamente al cargar páginas. Cron seguirá ejecutándose cuando llames a wp-cron.php directamente (que es exactamente lo que haremos en el paso 2).

Paso 2: Añadir un cron del servidor que llame a wp-cron.php

En el panel de control del hosting (o vía crontab SSH), crea un cron que se ejecute cada 5 minutos.

Con wget:

wget -q -O - https://tudominio.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Con curl:

curl -s https://tudominio.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Este enfoque hace cron independiente del tráfico. Tus tareas se ejecutan cuando el servidor lo ordena, no cuando alguien visita por casualidad.

¿Cuándo conviene pasar a cron real?

Si tu sitio es más que un blog de hobby, el cambio suele merecer la pena. Es especialmente recomendable cuando el horario importa o cuando los trabajos en segundo plano forman parte del negocio.

• Tiendas WooCommerce (pedidos, suscripciones, correos, tareas de stock)
• Sitios de membresía y plataformas de cursos
• Sitios que dependen de correos programados o automatizaciones
• Sitios con copias de seguridad, análisis de seguridad o monitorización
• Sitios con mucho tráfico donde las comprobaciones de cron añaden carga

WP-Cron y seguridad: por qué importa la fiabilidad

Muchas funciones de seguridad y mantenimiento dependen de trabajos programados. Si cron es poco fiable, puedes acabar con tareas que «parecen activadas» en la interfaz pero simplemente no se ejecutan de forma consistente.

Eso puede significar:

• Análisis que se ejecutan tarde (o no se ejecutan)
• Tareas de limpieza que no ocurren, dejando basura y logs creciendo
• Comprobaciones programadas que fallan en silencio, reduciendo la visibilidad

Si usas un plugin de seguridad que depende de análisis programados o comprobaciones rutinarias en segundo plano, un cron real del servidor es la configuración más segura.

WP-Cron depende del tráfico para dispararse. Poco tráfico significa horarios tardíos. Mucho tráfico puede lanzar cron con demasiada frecuencia y añadir carga.

Para la mayoría de sitios en producción, desactiva el lanzamiento automático de WP-Cron y llama a wp-cron.php desde un cron real del servidor en un horario fijo.