WP-Cron no se está ejecutando

Vulnity Security programa sus comprobaciones de heartbeat mediante WP-Cron, el sistema de tareas interno de WordPress. Esta guía cubre los avisos que aparecen cuando esas tareas programadas están desactivadas o no se ejecutan de forma fiable.

Cuándo usar esta guía

Usa esta guía si Vulnity muestra mensajes como:

External cron required
Heartbeat schedule missing
Heartbeat delayed
Traffic fallback active
No recent heartbeat success

Si en cambio ves Traffic fallback covering monitoring o External cron confirmed, son informativos: la monitorización está confirmada y no requieren acción (mira Vulnity lo cura automáticamente).

Qué significa

Vulnity envía heartbeats periódicos desde WordPress para confirmar que la web sigue conectada.

Esos heartbeats se programan mediante las tareas internas de WordPress. Si WP-Cron está desactivado, bloqueado o no se ejecuta con regularidad, la web puede aparecer como desconectada aunque el plugin siga instalado.

Esto también puede afectar a otras tareas de WordPress, como emails diferidos, copias de seguridad, publicaciones programadas, actualizaciones, tareas de caché y procesos de WooCommerce.

Solución recomendada

Configura un cron real del servidor que llame a wp-cron.php de forma periódica.

Esta es la configuración recomendada cuando DISABLE_WP_CRON está activado en wp-config.php.

Solución desde el panel de hosting

Accede al panel de control del hosting.
Busca Cron Jobs, Tareas programadas o una sección similar.
Crea una tarea que se ejecute cada 5 o 10 minutos.
Configúrala para llamar a:

https://example.com/wp-cron.php?doing_wp_cron

Sustituye example.com por el dominio real.

Solución por SSH

Desde el editor de cron del servidor, añade:

*/10 * * * * curl -fsS https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Sustituye example.com por el dominio real.

Si curl no está disponible, usa wget:

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

Si hay firewall o WAF

Asegúrate de que las peticiones a wp-cron.php no están bloqueadas por:

Reglas del firewall del hosting.
Reglas del WAF.
Plugins de seguridad.
Autenticación básica.
Restricciones por IP.
Reglas de caché que bloqueen ejecución PHP.

Vulnity lo cura automáticamente

Desde el plugin 1.4.0 el fallback por tráfico es auto-curativo. Cuando la web recibe visitas al admin o tráfico público y el último heartbeat está desactualizado, el plugin:

Envía un heartbeat no bloqueante para que el panel de Vulnity siga viendo la web online.
Intenta ejecutar la comprobación programada real en una petición aparte (relanzando WP-Cron directamente, o mediante un runner interno de un solo uso) para que el heartbeat quede confirmado y el aviso se limpie solo, sin añadir latencia a las visitas.

Gracias a esto, la mayoría de los fallos puntuales de WP-Cron se arreglan solos sin hacer nada:

Mensaje	Qué hacer
`Traffic fallback covering monitoring`	Nada — la monitorización está confirmada a través del fallback. Un cron externo sigue siendo la configuración recomendada.
`External cron confirmed`	Nada — los heartbeats se confirman según lo programado incluso con `DISABLE_WP_CRON`.
`Traffic fallback active`, `Heartbeat delayed`, `External cron required`, `Heartbeat schedule missing`, `No recent heartbeat success`	Sigue esta guía. El aviso global solo aparece tras más de 24 horas sin un heartbeat confirmado.

El fallback necesita tráfico: no sustituye a un cron real en webs sin tráfico o con muy poca actividad.

Verificación

Señales de éxito:

El aviso de Vulnity desaparece.
El panel de WordPress muestra WP-Cron healthy.
La web se mantiene conectada en Vulnity sin reactivaciones manuales.
Los heartbeats llegan varias veces al día en vez de solo tras acciones manuales.