WP-Cron is not running
Vulnity Security schedules its heartbeat checks through WP-Cron, WordPress’s internal task system. This guide covers the warnings shown when those scheduled tasks are disabled or not running reliably.
When to use this guide
Section titled “When to use this guide”Use this guide if Vulnity shows messages such as:
External cron requiredHeartbeat schedule missingHeartbeat delayedTraffic fallback activeNo recent heartbeat success
If instead you see Traffic fallback covering monitoring or External cron confirmed, those are informational: monitoring is confirmed and no action is required (see Vulnity heals this automatically).
What it means
Section titled “What it means”Vulnity sends periodic heartbeat checks from WordPress to confirm that the site is still connected.
Those heartbeats are scheduled through WordPress tasks. If WP-Cron is disabled, blocked, or not triggered regularly, the site may appear disconnected even though the plugin is still installed.
This can also affect other WordPress tasks such as delayed emails, backups, scheduled publishing, plugin updates, cache jobs, and WooCommerce jobs.
Best solution
Section titled “Best solution”Use a real server cron that calls wp-cron.php regularly.
This is the recommended setup when DISABLE_WP_CRON is enabled in wp-config.php.
Hosting-panel solution
Section titled “Hosting-panel solution”- Open your hosting control panel.
- Find Cron Jobs, Scheduled Tasks, or a similar section.
- Create a task that runs every 5 to 10 minutes.
- Configure it to request:
https://example.com/wp-cron.php?doing_wp_cronReplace example.com with the real domain.
SSH solution
Section titled “SSH solution”From the server cron editor, add:
*/10 * * * * curl -fsS https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1Replace example.com with the real domain.
If curl is not available, use wget:
*/10 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1If a firewall or WAF is enabled
Section titled “If a firewall or WAF is enabled”Make sure requests to wp-cron.php are not blocked by:
- Hosting firewall rules.
- WAF rules.
- Security plugins.
- Basic authentication.
- IP restrictions.
- Cache rules that block PHP execution.
Vulnity heals this automatically
Section titled “Vulnity heals this automatically”Since plugin 1.4.0 the traffic fallback is self-healing. When the site receives admin or public traffic and the last heartbeat is stale, the plugin:
- Dispatches a non-blocking heartbeat so the Vulnity panel keeps seeing the site online.
- Tries to run the real scheduled check in a separate request (re-spawning WP-Cron directly, or through an internal single-use runner) so the heartbeat is confirmed and the warning clears itself, without adding any latency for visitors.
Because of this, most WP-Cron hiccups fix themselves without any action:
| Message | What to do |
|---|---|
Traffic fallback covering monitoring | Nothing — monitoring is confirmed through the fallback. An external cron is still the recommended setup. |
External cron confirmed | Nothing — heartbeats are confirmed on schedule even with DISABLE_WP_CRON. |
Traffic fallback active, Heartbeat delayed, External cron required, Heartbeat schedule missing, No recent heartbeat success | Follow this guide. The sitewide warning only appears after more than 24 hours without a confirmed heartbeat. |
The fallback needs traffic: it is not a replacement for a real cron on idle or low-traffic sites.
Verification
Section titled “Verification”Signs of success:
- The Vulnity warning disappears.
- The WordPress dashboard shows
WP-Cron healthy. - The site remains connected in Vulnity without manual reactivation.
- Heartbeats arrive several times per day instead of only after manual actions.