Why this happens: WP-Cron isn’t a real clock
Most people assume WordPress has a built-in clock that runs scheduled jobs on time. It does not. As the WordPress Plugin Handbook explains, WP-Cron is a “pseudo-cron” that only checks for due tasks when someone loads a page. On a busy site, that is often enough — there is always a visitor to trigger it. On a quiet site, an hour can pass with no visitors, so a job scheduled for 9am simply does not run until someone shows up.
It gets worse on exactly the sites that need reliability. Aggressive page caching can serve visitors without ever booting WordPress, so WP-Cron never fires. And some hosts or security rules block the internal “loopback” request WP-Cron uses to call itself — so even with traffic, nothing triggers.
Symptoms that point at WP-Cron
WP-Cron failures look like a scattering of unrelated bugs until you notice they are all scheduled tasks.
- Scheduled posts miss their publish time (or post late, when a visitor finally arrives).
- Backups stop running on schedule.
- WooCommerce subscription renewals or other plugin jobs are delayed.
- Queued or transactional emails do not send.
- Security scans, reports, or digest emails stop arriving.
The recommended fix: a real server cron
For any business-critical site, the reliable fix is to stop depending on visitors and let the server keep time. Following the official guide to hooking WP-Cron into the system task scheduler: first disable the visitor-triggered behaviour by adding define( 'DISABLE_WP_CRON', true ); to wp-config.php, then set a real server cron (via your host’s control panel or crontab) to request wp-cron.php on a fixed schedule — every 5 to 15 minutes is typical.
This makes scheduled work predictable. The clock now belongs to the server, not to whoever happens to visit, so backups run, posts publish, and emails send on time regardless of traffic.
Default WP-Cron vs a real server cron
The difference matters most on exactly the sites that can least afford missed jobs.
| Aspect | Default WP-Cron | Server cron |
|---|---|---|
| Trigger | A visitor loading a page. | The server clock, on a fixed schedule. |
| Low-traffic reliability | Poor — jobs wait for a visitor. | Reliable regardless of traffic. |
| Affected by page caching | Yes — cached hits can skip it. | No. |
| Best for | Busy sites, casual blogs. | Stores, membership, anything business-critical. |
| Setup | None (default). | Disable WP-Cron + add one server cron job. |
WP-Cron mistakes to avoid
- Assuming WordPress runs scheduled jobs on a real clock — it does not, by default.
- Disabling WP-Cron with DISABLE_WP_CRON but forgetting to add the replacement server cron, which stops all scheduled jobs entirely.
- Setting the server cron too frequently (every minute) on a small host, adding needless load.
- Blaming the backup or email plugin when the real cause is the scheduler that triggers it.
- Ignoring late scheduled posts as a quirk instead of an early warning sign.
How we handle scheduling on managed sites
In our experience, WP-Cron is one of the most common silent failures on lower-traffic business sites — the backups “run,” the reports are “set up,” and yet nothing actually fires because no visitor triggered it. So on managed sites we move scheduling to a real server cron as standard and monitor that the jobs that matter — especially backups — are genuinely completing, not just configured. It is a small change that quietly underpins the whole maintenance routine.
- Switch business-critical sites to a server cron rather than visitor-triggered WP-Cron.
- Always pair DISABLE_WP_CRON with a working replacement cron.
- Verify backups and key jobs actually complete, not just that they are scheduled.
- Watch for late scheduled posts as an early symptom of a broken trigger.
Frequently asked questions.
Is WP-Cron bad?
No — it is genuinely useful and fine for busy sites with steady traffic. The problem is relying on visitor-triggered scheduling for business-critical jobs on a quieter site, where there may be no visitor to trigger it when a task is due.
Can broken WP-Cron stop my backups?
Yes. Many backup plugins rely on WordPress scheduled events, so if WP-Cron is not firing, the backups quietly stop — often without any error. This is why we verify backups actually complete rather than trusting that they are scheduled.
How do I switch to a real server cron?
Add define( 'DISABLE_WP_CRON', true ); to wp-config.php to stop the visitor-triggered behaviour, then create a server cron job (in your host’s control panel or crontab) that requests wp-cron.php every 5–15 minutes, following the official WordPress guide. Crucially, do not disable WP-Cron without adding the replacement, or all scheduled jobs stop.
Why do my scheduled posts publish late?
Late scheduled posts are a classic WP-Cron symptom: the post was due but no visitor arrived to trigger the scheduler until later. A server cron fixes it by triggering WordPress on a fixed schedule regardless of traffic.
Research sources.
This guide was checked against current platform and search documentation before publication.