Quick answer: Default WP-Cron depends on requests reaching WordPress, so scheduled posts and maintenance tasks can run late on low-traffic sites. A supported server scheduler can trigger due work without waiting for visitors. It changes how WordPress starts scheduled work—not the tasks themselves. Verify your host’s existing setup, test the replacement in staging, and confirm task completion before disabling request-triggered WP-Cron. Neither method guarantees exact execution times. (developer.wordpress.org)
1. Why scheduled WordPress tasks run late
WordPress uses WP-Cron for time-based work, including publishing scheduled posts and checking for updates. In its default configuration, requests to WordPress provide opportunities to check for due events. WP-Cron is not a continuously running system scheduler. (developer.wordpress.org)
That distinction matters on a quiet website. Suppose a post is due at 9:00 a.m., but no request reaches WordPress until 9:40 a.m. The default trigger may not start the publication work until that later request. WordPress’s own documentation describes this traffic-dependent delay. (developer.wordpress.org)
Visitor counts alone are not a reliable diagnostic. SiteGround notes that caching plugins can interfere with WP-Cron execution. Ask whether requests actually reach WordPress and whether your host already provides an independent trigger. (siteground.com)
Separate three questions:
- Scheduling: Does the event exist with the intended due time?
- Triggering: Did a scheduler start WordPress’s due work?
- Completion: Did the callback finish and produce its intended effect?
WP-Cron events need both a scheduled event and a registered callback. Improving the trigger cannot fix a missing callback or incorrectly registered event. (developer.wordpress.org)
2. Choose based on timing needs, not traffic alone
Keep default WP-Cron when occasional delays are acceptable and you have no evidence that scheduled work is being neglected. Consider a host-supported scheduler when work needs to start consistently during periods without visitors. WordPress officially documents connecting its cron runner to a system task scheduler for this purpose. (developer.wordpress.org)
Use these decision criteria:
| Your situation | Practical next step |
|---|---|
| Tasks are not time-sensitive and appear to complete | Keep the current setup and periodically inspect overdue events |
| Scheduled posts remain unpublished through quiet periods | Test an independent trigger |
| The host already manages WordPress scheduling | Confirm its interval and monitoring before adding anything |
| Tasks start but fail or run too long | Investigate the callback and execution environment |
| The platform does not offer server cron | Follow its supported scheduling guidance |
Server cron is not a replacement for WordPress’s event registry. It can periodically invoke the WordPress runner, which then processes due events. You do not need to recreate each plugin’s schedule as a separate operating-system job. (developer.wordpress.org)
Before changing anything, write down your acceptable delay. “Publish within several minutes” and “publish at precisely 9:00:00” are different requirements. A periodic trigger is useful for the first; do not assume it satisfies the second.
3. Check which execution options your host supports
Ask your provider which method it supports for your specific plan:
- A control-panel cron job.
- A system scheduler available through SSH.
- A managed scheduler configured by support.
- Periodic HTTPS requests to the WordPress cron endpoint.
- Scheduled WP-CLI execution.
WordPress documents HTTP requests to wp-cron.php; WP-CLI provides a command to run events that are currently due. cPanel also documents a Cron Jobs interface, but hosting providers can disable that interface. (developer.wordpress.org)
Provider examples checked on October 4, 2026:
- Kinsta: Its published WordPress cron policy specifies a five-minute minimum interval and limits support to installing or editing the job as directed. It also warns customers not to alter provider-managed entries. (kinsta.com)
- SiteGround: Its tutorial uses Site Tools and WP-CLI, with a twice-hourly example. That is tutorial guidance, not evidence of a universal minimum interval. (siteground.com)
- WordPress.com: Its developer documentation says traditional server-side cron is unavailable and describes supported ways to make request-triggered WP-Cron more consistent. Do not apply a self-hosted
crontabtutorial indiscriminately. (developer.wordpress.com)
For your account, confirm the minimum interval, runtime and memory limits, available PHP or WP-CLI executable, execution user, logging, and staging support. The cited documents do not establish a universal execution-time limit across hosts.
4. Set the interval and time zone deliberately
A five-minute polling schedule means checking for due work every five minutes—not publishing every post exactly at its selected minute.
For an illustrative calculation, suppose successful triggers occur at 10:00, 10:05 and 10:10:
| Event | Due time | Next polling opportunity | Waiting time |
|---|---|---|---|
| Synthetic post | 10:02 | 10:05 | 3 minutes |
| Maintenance marker | 10:07 | 10:10 | 3 minutes |
These are hypothetical opportunities, not measured results. They assume no earlier trigger and a successful runner. Startup delay and task execution add time beyond the polling wait. The calculation follows the periodic scheduling approach documented by WordPress. (developer.wordpress.org)
In conventional five-field cron syntax, the schedule:
*/5 * * * *
selects every fifth minute. It is only the schedule portion; it still needs a host-approved command. Confirm that your provider permits that interval. (developer.wordpress.org)
Check Settings → General → Timezone before scheduling a test post. WordPress recommends selecting a city in the intended time zone; its scheduling API uses Unix timestamps representing UTC instants. (wordpress.org)
Separately confirm the scheduler’s time zone. Kinsta documents UTC for its servers, but that does not establish another host’s configuration. Record the zone alongside every test timestamp, and verify seasonal offsets when using wall-clock schedules. (kinsta.com)
5. Prevent overlapping runs and hidden failures
A shorter interval is not automatically better. cPanel warns that a new invocation can begin before the previous one finishes, potentially degrading performance. (docs.cpanel.net)
WordPress’s HTTP spawning code includes a cron lock intended to coordinate spawning. Do not treat that as a blanket guarantee that every custom callback—or a different execution path—cannot overlap. (developer.wordpress.org)
Before adopting the replacement:
- Inventory existing triggers, including host-managed jobs.
- Record runner start, finish and duration.
- Ask whether the scheduler prevents concurrent invocations.
- Investigate unusually long callbacks before increasing frequency.
- Keep errors visible during testing.
For a host-supported WP-CLI setup, the relevant command is:
wp cron event run --due-now
It runs events due now. Do not substitute --all merely to “make sure everything runs”; that option runs all hooks rather than limiting execution to due work. This is command syntax, not a complete production cron entry: your host must confirm the executable, site path, user and logging arrangement. (developer.wordpress.org)
Avoid immediately copying output suppression such as >/dev/null 2>&1. SiteGround explicitly notes that removing it from its example allows execution notifications. Retain useful diagnostic output until verification is complete. (siteground.com)
6. Test a synthetic post and harmless maintenance task in staging
Back up files, the database and scheduler configuration first. Use isolated staging with outbound email, payments and external integrations disabled or redirected. The following is a proposed test—not a report of hands-on results.
Prepare two observable tasks.
- Create a clearly labeled post containing no customer information. Schedule it a few minutes ahead using the site’s displayed time zone.
- Have a developer register a one-time staging event with a unique hook, such as
sha_staging_scheduler_marker. Its callback should only update a dedicated test option with the actual UTC execution timestamp.
WordPress provides wp_schedule_single_event() for one-time events and update_option() for writing an option value. Register the callback before scheduling the event and check that scheduling succeeded. (developer.wordpress.org)
This marker is a harmless stand-in for maintenance work: it should not delete files, alter customer records, call an AI API or send messages.
Run a controlled comparison.
- Record both due times and confirm that the marker appears in the event list.
- For the default-trigger test, avoid dashboard refreshes and other deliberate WordPress requests during the quiet period. Record known monitoring traffic.
- Configure the replacement scheduler while request-triggered WP-Cron remains enabled.
- Confirm that the replacement successfully reaches the staging installation and runs due work.
- Then disable request-triggered spawning in staging only, create fresh test events, and repeat through automatic scheduler ticks.
WP-CLI’s wp cron event list can inspect events, and wp option get can retrieve the marker. Prefer inspecting afterward so dashboard activity does not obscure which trigger caused execution. (developer.wordpress.org)
Record:
| Check | Evidence to retain |
|---|---|
| Correct schedule | Due timestamp and time zone |
| Runner started | Scheduler log or command output |
| Post completed | Post status changed to Published |
| Marker completed | Stored execution timestamp |
| No overlap | Runner start and finish records |
Do not rely only on the post’s displayed publication date; capture an independent observation time. Do not count a manually clicked “Run now” as proof that the automatic schedule works.
7. Disable request-triggered WP-Cron only after verification
Once staging shows automatic execution, document the replacement and plan the production change.
WordPress documents this configuration setting:
define( 'DISABLE_WP_CRON', true );
Add or update it in wp-config.php before WordPress loads, following your host’s configuration guidance. Do not create duplicate definitions. This switches off normal request-triggered spawning; the replacement must continue invoking WordPress’s scheduled work. (developer.wordpress.org)
Before production cutover, confirm:
- A tested backup and saved original configuration.
- The correct production path or endpoint.
- A permitted interval and execution method.
- Visible failures and an identified person responsible for checks.
- A documented way to restore the previous trigger.
One common diagnostic mistake is running wp cron test after disabling request-triggered WP-Cron and treating its error as proof that server cron failed. That command tests spawning and explicitly errors when DISABLE_WP_CRON is true. Use scheduler logs and completed test work to assess the replacement. (developer.wordpress.org)
8. Monitor completion and keep rollback simple
After cutover, inspect automatic runs, overdue events and actual task outcomes. An empty due-event list is useful evidence, but it should not replace checking whether important work completed. WordPress’s event-list command provides scheduling visibility, not a universal success report for every callback. (developer.wordpress.org)
Keep this rollback checklist:
- Pause the custom replacement job, coordinating with the host if it manages the entry.
- Remove or revert the
DISABLE_WP_CRONsetting. - Make a controlled request and check due work.
- Review overdue events before manually triggering anything.
- Remove the staging marker, test option and synthetic post when testing is finished.
Restoring request-triggered WP-Cron also restores its dependence on traffic. It is a fallback, not a solution to the original low-traffic delay. (developer.wordpress.org)
The useful improvement is not simply “server cron enabled.” It is a supported trigger, an appropriate interval, observable completion, and a recovery path when execution stops.