WP-Cron problems and real server cron

The short answer

WP-Cron is the scheduler inside WordPress that runs tasks like scheduled posts, backups and WooCommerce emails. It only runs when someone visits your site, so on a quiet site or a heavily cached site, tasks run late or not at all. The fix is to switch WP-Cron off and have the server’s own scheduler (real cron) trigger it every five minutes instead.

What it means

A real scheduler runs on a clock. WP-Cron does not. On each page load, WordPress checks whether any task is overdue and, if so, fires a quick background request to a file called wp-cron.php to run it. That design has three weak spots.

First, no visitors means no cron, so a post scheduled for midnight publishes whenever the next person turns up. Second, page caching serves most visitors a saved copy of the page without running WordPress at all, so the check never happens. Third, on a busy site the check runs on every visit, adding load, and a slow task can overlap with the next one.

The symptoms are familiar: Missed schedule on posts, order emails arriving late, backups that silently stop, a growing backlog under WooCommerce Scheduled Actions, and a Site Health warning that a scheduled event has failed.

Common causes

• Low or cached traffic. The most common cause by far. Caching makes a site faster and, as a side effect, starves WP-Cron of triggers.
• A failed loopback request. The server cannot call its own web address, often because of a firewall rule, a DNS quirk or password protection on a staging site. Site Health reports this directly.
• WP-Cron disabled with nothing to replace it. Someone added DISABLE_WP_CRON to wp-config.php in the past and never set up a server cron.
• A stuck or very long task blocking the queue, usually a plugin doing heavy work, or a huge Action Scheduler backlog in WooCommerce.
• A plugin leaking events, registering a fresh scheduled event on every page load until there are thousands of duplicates.

How to fix it

1. See what is scheduled. Install the WP Crontrol plugin and go to Tools, then Cron Events. It lists every event, when it is next due, and lets you run one on demand. A list with thousands of near-identical entries points at a leaking plugin. Also check Tools, then Site Health, for cron or loopback warnings.
2. Turn off the visitor-triggered cron. Open wp-config.php in File Manager and add define('DISABLE_WP_CRON', true); above the line that says that is all, stop editing. This step is host independent. Do not stop here, or nothing will run at all.
3. Create a real server cron. In the management console (Plesk with WP Toolkit) go to Websites & Domains, then Scheduled Tasks (also under Tools & Settings, then Scheduled Tasks), and add a task. The cleanest option is a command that runs WP-CLI from your site’s folder: wp cron event run --due-now. If WP-CLI is not an option, choose the Fetch a URL task type and point it at https://www.example.com/wp-cron.php?doing_wp_cron with your own domain. Set it to run every five minutes, which in cron notation is */5 * * * *.
4. Check for a built-in switch. WP Toolkit can take over wp-cron.php for a site from the site card, which does steps two and three for you. VERIFY: the exact label of that setting in the current WP Toolkit version.
5. Confirm it is running. Back in WP Crontrol, the next run times should now move forward on their own, and a post scheduled a few minutes ahead should publish on time. The Site Health warning should clear.
6. Clear the backlog. In WP Crontrol delete duplicate or orphaned events whose plugin no longer exists. In WooCommerce, go to Status, then Scheduled Actions, and look at the Pending count. Once real cron is running it will work through the list; if it is enormous, give it a day before judging.
7. Fix loopback failures if they remain. If Site Health still reports that the loopback request failed, the server cannot reach its own address. Password protection on a staging site is the usual cause; add an exception for wp-cron.php or rely on the WP-CLI command instead, which does not need a web request.
8. Watch it for a week. Scheduled posts, backup emails and order notifications should all arrive on time. If one plugin still lags, its task is slow rather than unscheduled, and that is a different conversation.

On WP Alpha

Real server cron is available on WP Alpha, along with SSH and WP-CLI, so the five-minute WP-CLI task above is the recommended setup. Scheduled Tasks live in the management console (Plesk with WP Toolkit) under Websites & Domains. VERIFY: whether server cron for wp-cron.php is set up automatically on new sites, or whether customers add it themselves.

Page caching and Redis object caching are on every plan and Cloudflare sits in front of every site, which is exactly why visitor-triggered WP-Cron is unreliable here: most visitors never hit WordPress at all. Moving to server cron turns that from a weakness into a non-issue. If you would like it set up for you, support is available 24/7 by live chat and ticket.