Replacing WP-Cron with a real scheduler
WP-Cron is not cron. It runs when someone loads a page, which means a quiet site misses its schedule and a busy site pays for the check on every request. The documented fix is an external scheduler, and that is exactly what this is.
What WordPress gives you
WP-Cron. WordPress checks for due tasks on page load. Posts publish, backups run and updates check because a visitor happened to arrive at the right moment.
- What triggers it
- An incoming page request
- If nobody visits
- Nothing runs
- Accuracy
- Best-effort, tied to traffic
- Documented fix
- DISABLE_WP_CRON plus an external request
Checked against WordPress plugin handbook on 18 August 2026. These change — if a deploy disagrees with this page, believe the deploy and tell us.
When this is the right answer
Most people reading this should keep what they have. It is worth being specific about when:
- The site gets steady traffic all day and nothing you schedule is time-critical.
- Your host already replaced WP-Cron with a real system cron — many managed WordPress hosts do this for you.
Where it runs out
A quiet site simply does not run its jobs
A post scheduled for 03:00 publishes when the first visitor arrives — which on a low-traffic site can be hours. The classic symptom is "missed schedule" on a scheduled post.
A busy site pays for it on every request
The check is spawned on page loads, so the mechanism is either unreliable or overhead, depending on your traffic. It is never quite free.
Two visitors at once can double-fire a task
WP-Cron guards against this with a lock, but under real concurrency the guard is doing work your scheduler should not have needed to do.
Scheduling it from outside
Two steps, both from the WordPress plugin handbook. Turn off the traffic-driven behaviour, then have something reliable call the endpoint instead.
wp-config.php
define( 'DISABLE_WP_CRON', true );Then point a getNodi job at https://your-site.com/wp-cron.php?doing_wp_cron on whatever schedule you want — every five minutes is a common choice. You get a record of every call, and an alert when your site stops answering, which doubles as uptime monitoring you were not previously doing.
What getNodi adds
getNodi calls a URL on a schedule and tells you what happened. Any schedule down to your plan’s floor, in your timezone rather than UTC, with retries, a record of every run — status, latency, response — and an alert the first time one fails. Credentials are encrypted at rest and requests can be HMAC-signed so your endpoint can verify they came from us.
The free plan runs 3 jobs hourly and needs no card, which is enough to find out whether this works for you. What it will not do is run a container, hold a connection open for an hour, or execute your code — it makes HTTP requests, and everything above is a way of making that enough.