wp-cron Not Running? The Block Nobody Checks

Scheduled posts silently skip, backups stop running, sitemaps go stale and sync plugins freeze half-finished — and Search Console never says why. On shared hosting the reason is often the simplest one: your firewall is blocking requests to wp-cron.php because they look like bots.

Quick answer

Test it the way WordPress does: curl -A "WordPress/" -I https://yoursite.com/wp-cron.php?doing_wp_cron. A 200 means the request is allowed; a 403 means your firewall's crawler rules are eating it. Because wp-cron requests carry no cookies and a generic user agent, they are first in line for crawler blocks. The fix is to normalize the user-agent for wp-cron traffic before the firewall reads it.

How the block works

Bad user-agent rules. Firewalls block the WordPress UA pattern because bots spoof it.
No cookies, no referer. wp-cron requests fail most human-visitor heuristics by design.
Silent failure. The block returns an error page; every scheduled hook that minute simply does not run. No dashboard warning tells you.
Half-finished syncs. Long-running jobs (listing imports, sitemap rebuilds) die mid-batch and leave stale state that makes the next run look healthy.

The DIY fix

Curl wp-cron with the WordPress UA from outside your network and read the status code.
If 403: locate the firewall layer blocking it (host WAF, security plugin) and whitelist the wp-cron path, or better, normalize the UA before the firewall evaluates.
A mu-plugin loaded before your security plugins, which sets a browser-styled UA for wp-cron requests, survives plugin updates and covers firewall layers that read the UA later.
Then clear any stuck schedule locks and watch the next scheduled event complete.

The Brambyl route

The cron reachability check probes wp-cron exactly as WordPress would and flags a block as critical. The PRO repair deploys the mu-plugin, and the plugin self-test runs on every scan so a future firewall change on your host shows up as a finding instead of a silent failure.

FAQ

I use DISABLE_WP_CRON with a real cron job. Does this affect me?

No — but if your real server cron hits wp-cron.php over HTTP, the same block can still apply, so test it the same way and watch for 403.

Why did my sitemap go stale for weeks?

Low-traffic sites rely on wp-cron for sitemap regeneration. A blocked wp-cron plus no visitors equals no rebuild. This is one of the quiet causes of the discovered-not-indexed state.

Is this shared-hosting specific?

Any WAF in front of WordPress can do it, but shared hosting plans ship aggressive crawler defaults, so the class is most common there.