Scheduled tasks miss their time on shared hosting because WP-Cron, WordPress's built-in scheduler, only checks due jobs when someone loads a page. If no visit happens at the due time, nothing runs until the next visit. Many shared hosts do not offer access to a true system scheduler, so visits must do the work. That gap delays posts, emails, backups, and update checks even when settings look correct.
Table of Contents
- How visit-triggered scheduling slips
- Why shared hosting feels it most
- What else stops the trigger
- How to get on-time runs
How visit-triggered scheduling slips
WP-Cron stores scheduled tasks and inspects the list on every page load. It runs anything due as part of that load, rather than running continuously like Unix system cron. According to the WordPress Developer Docs, how WP-Cron runs on page load explains this visit-only check.
A low-traffic site therefore misses exact times. A task set for 2:00 PM may wait until a 5:00 PM visit. Overdue tasks stay queued and run at the next opportunity. They arrive late rather than lost, while busy sites pay the opposite price in extra load and slower response on triggering visits.
Why shared hosting feels it most
Shared plans often lack access to the server scheduler. Without that always-on timer, WordPress must simulate scheduling with visits. Small business sites, portfolios, and new blogs have long quiet hours.
Night, weekends, and holidays create the longest gaps between checks. Traffic timing then controls task timing. One visitor at noon can release several morning jobs at once.
What else stops the trigger
When work is due, WordPress sends a non-blocking loopback request to its own wp-cron.php file. Blocked loopbacks, DNS failures, firewalls, or password protection on staging stop that self-request, so scheduled posts and checks never fire. Full-page caching makes misses worse.
According to ACF / WP Engine, why cached pages skip WP-Cron is that a cached HIT serves saved HTML without starting WordPress, so those visits never inspect the schedule. Staging logins and strict security rules cause the same silence. The schedule looks active, but the trigger never reaches the code.
How to get on-time runs
The reliable fix separates timing from visitors. Site owners disable page-load triggering and let the real server scheduler call wp-cron.php on a set interval.
According to the WordPress Developer Docs, hooking WP-Cron into the system scheduler describes this setup. Replace the example address with the real site address. Keep the interval short for time-sensitive posts and longer for nightly maintenance.
- Add define('DISABLE_WP_CRON', true); to wp-config.php above the database settings.
- Ask the host for scheduled-task or cron support, or use an external scheduler.
- Point that scheduler at wp-cron.php every 15 minutes or nightly, for example with wget –delete-after http://your_site_url/wp-cron.php`.
