You scheduled five posts for the week. Monday’s went live on time. Tuesday’s published three hours late. Wednesday’s never published at all until you manually clicked Publish. Thursday’s showed “Missed schedule” in red. If you are running automated content through ClearPost or any publishing workflow, this is the failure pattern: inconsistent, silent, and maddening. The cause is almost never the content tool. It is the scheduling layer underneath WordPress that nobody explains.
WordPress does not have a real scheduler. Scheduled posts, plugin update checks, backup jobs, and SEO scans all depend on a pseudo-cron system called wp-cron that only runs when someone visits your site. On a low-traffic blog, that means scheduled posts wait for visitors. When two plugins both try to manage the same scheduling mechanism, things break further. Here is how the system actually works, where it fails, and how to confirm a scheduled post will fire before you trust it.
How WordPress Scheduling Actually Works
When you click “Schedule” in the WordPress editor, WordPress does not set a timer. It calls wp_schedule_single_event() with a hook named publish_future_post and the post ID as an argument. That event is stored in the wp_options database table under the cron key, alongside every other scheduled task from every plugin on your site. The event sits there until something triggers wp-cron to check for due tasks.
That trigger is a page load. On every uncached request that reaches PHP, WordPress calls spawn_cron(), which checks whether any scheduled events are past their due time. If they are, WordPress sends a non-blocking HTTP request back to wp-cron.php on the same server. That request executes the due tasks, including publish_future_post, which changes the post status from “future” to “publish.” The visitor who triggered the check never sees a delay.
The critical dependency: no visitors, no cron. A post scheduled for 9 AM on a Sunday will not publish until the first person lands on your site after 9 AM. On a low-traffic blog, that could be hours. On a staging site, it could be days. WordPress knows the post is due. The scheduler just has no trigger to act on it. For a full breakdown of how wp-cron works and why it fails, our wp-cron troubleshooting guide covers every failure mode in detail.
Why Low-Traffic Sites Break Scheduled Publishing
The traffic dependency is not a bug. It is the core design of wp-cron, and it is documented in the WordPress Developer Resources: “The action will trigger when someone visits your WordPress site if the scheduled time has passed.” On a busy site with hundreds of visitors per hour, this works fine. The scheduler fires within seconds of any due task. On a site getting 20 visitors a day, a post scheduled for 9 AM might not publish until 2 PM when someone finally lands.
Full-Page Caching Makes It Worse
If your site uses Varnish, nginx fastcgi_cache, LSCache, or Cloudflare full-page caching, most requests never reach PHP at all. WordPress never bootstraps, spawn_cron() never fires, and scheduled tasks silently miss their window. A site can serve thousands of cached pages per hour while every scheduled job quietly fails. The site looks fast and healthy from the visitor’s perspective. The failure is invisible.
DISABLE_WP_CRON Without a Replacement
A common performance optimization tells you to add define('DISABLE_WP_CRON', true); to wp-config.php to stop the per-page-load cron check. This is good advice, but only if you immediately set up a real system cron job to replace it. If you disable the page-load trigger and do not configure a replacement, every scheduled event silently stops. Scheduled posts never publish. Plugin update checks never run. Backups never fire. The site appears to work, but nothing scheduled ever executes. If your host added this constant during a migration or performance pass and never told you, this is the first thing to check.
When Two Plugins Both Manage Scheduling
Here is the scenario that catches people off guard: your SEO plugin schedules a broken-link scan every hour. Your backup plugin schedules a backup every 12 hours. Your content automation plugin schedules post publishing events. Each plugin calls wp_schedule_event() or wp_schedule_single_event() independently, and they all write to the same cron option in the database. This usually works fine because WordPress deduplicates events with the same hook and arguments. But it breaks in three specific ways.
Duplicate Events from Missing wp_next_scheduled Checks
The correct pattern for scheduling a recurring event is to check whether it already exists first:
if ( ! wp_next_scheduled( 'my_cron_hook' ) ) { wp_schedule_event( time(), 'hourly', 'my_cron_hook' ); }
If a plugin developer skips the wp_next_scheduled() check and calls wp_schedule_event() on every page load or on a frequently-fired hook like init, WordPress ends up with dozens of identical scheduled events. The cron option in the database grows unbounded, which slows down every page load (it is loaded on every request), and the same task executes multiple times per cycle. This produces duplicate backups, double-published posts, or SEO scans running back-to-back. The WordPress core code comments this risk directly: mismatched arguments can lead to “duplicate cron events being scheduled unintentionally, excessive growth of the cron option, and database performance issues.”
Argument Mismatch Creates Ghost Duplicates
WordPress identifies scheduled events by a combination of the hook name and the arguments passed to it. The arguments are serialized and hashed with MD5 to create a unique key. If a plugin schedules an event with arguments like array( 'post', 42 ) but later checks for it with array( 'post', '42' ) (integer versus string), WordPress treats them as different events. The existing event is not found, a new one is scheduled, and the old one is never cleaned up. Over weeks, the cron queue fills with ghost duplicates that all fire for the same task. This is one of the most insidious plugin conflicts because it produces no error message. It just silently degrades performance and causes unpredictable execution.
The doing_cron Lock and Race Conditions
WordPress uses a transient called doing_cron as a soft lock to prevent two cron processes from running simultaneously. When a cron spawn begins, WordPress sets this transient with a one-minute timeout. If a second page load triggers another spawn within that minute, the second process sees the lock and exits. This works most of the time. But on high-traffic sites or when two external cron jobs are configured (one by your host, one you added yourself), two processes can both pass the lock check within the same millisecond and both proceed. The result: a scheduled post might have its publish_future_post hook fire twice. WordPress core handles this gracefully for post publishing (the status change is idempotent), but other plugins are not always so careful. Duplicate backup runs, double-sent emails, and repeated index rebuilds all trace back to this race condition.
How to Test That a Scheduled Post Will Fire
You do not need to wait until tomorrow morning to find out if your scheduled post will publish. You can test the entire chain in under five minutes using the tools below. The goal is to confirm three things: the event exists in the cron queue, the cron system is actually triggering, and the publish_future_post hook fires when it should.
Method 1: WP Crontrol (No SSH Required)
Install the free WP Crontrol plugin from the WordPress.org directory. Go to Tools > Cron Events. You will see a list of every scheduled task on your site with its hook name, next run time, recurrence, and callback. Search for publish_future_post. If you have a post scheduled, you will see it listed with the post ID in the arguments column and the scheduled time as the next run.
Events past their scheduled time show a red “Missed” label. If you see missed events, your wp-cron is not firing on page loads. You can also click “Run Now” next to any event to manually trigger it. If a manually triggered event succeeds but the event keeps missing its schedule, the problem is the trigger mechanism, not the task itself.
WP Crontrol also shows spawning errors. If you see “There was a problem spawning a call to the WP-Cron system,” the plugin identifies the specific HTTP error. cURL error 28 means a timeout. HTTP 401 or 403 means something is blocking the server’s request to itself (BasicAuth, a security plugin, a firewall rule). HTTP 500 means a PHP error during the cron run.
Method 2: WP-CLI (If You Have Shell Access)
If you have SSH access and WP-CLI installed, you get the most direct diagnostic. From your WordPress root directory:
wp cron event list --fields=hook,next_run_relative,next_run_gmt shows all scheduled hooks and how far away their next run is. Filter to just the overdue ones with wp cron event list --due-now. If publish_future_post shows up in the due-now list, your scheduler is not firing.
wp cron test checks whether the cron system can spawn HTTP requests. If this returns an error, you have a loopback or connectivity problem. Do not run this command if you have already set DISABLE_WP_CRON to true, because it tests the visitor-triggered spawning path you intentionally disabled.
wp cron event run --due-now manually fires all overdue events. Use this to clear a backlog after fixing the underlying trigger issue. To force a specific scheduled post through immediately, run wp post update [post-id] --post_status=publish.
Method 3: Schedule a Test Post Five Minutes Out
This is the most practical end-to-end test. Create a draft post with a placeholder title like “Scheduling Test.” Set its publish time to five minutes from now. Click Schedule. Then watch what happens:
- If the post publishes within a minute of the scheduled time, your cron is working. You are done.
- If the post stays in “Scheduled” past its time, open WP Crontrol and check whether
publish_future_postshows as missed. If it does, your trigger is not firing. - If the post eventually publishes but hours late, you have a low-traffic or caching problem. The cron only fires when a visitor hits an uncached page.
- If the post never publishes even after visitors arrive, check for a
DISABLE_WP_CRONconstant with no replacement system cron configured.
The Fix: Replace the Traffic Trigger With a Real Cron
Every scenario above has the same root cause: relying on visitor traffic to trigger the scheduler. The fix is to disable the page-load trigger and replace it with a real system cron job that hits wp-cron.php on a fixed schedule. This decouples scheduled post publishing from site traffic entirely.
Add this line to wp-config.php, above the “stop editing” comment:
define( 'DISABLE_WP_CRON', true );
Then configure a system cron job to hit wp-cron.php every 5 minutes. In cPanel, go to Cron Jobs and add */5 * * * * as the schedule. If you have SSH access, the most reliable approach is WP-CLI running wp cron event run --due-now every minute, which avoids the HTTP loopback entirely. Every method is covered step by step in our wp-cron fix guide, including the exact crontab commands for each hosting environment.
Where ClearPost Fits In
ClearPost (our WordPress plugin) drafts SEO-optimized posts and delivers them to your approval queue inside WordPress. When you approve a post, you can schedule it for publishing at a specific time. That scheduling relies on the same publish_future_post hook every other WordPress scheduling mechanism uses. If wp-cron is not firing, the post sits in “Scheduled” until a visitor triggers the cron check. On a new or low-traffic blog, that could be hours or days.
This is one of the most common integration failures we see. A site owner sets up automated content, schedules posts throughout the week, and wonders why nothing publishes on time. The content pipeline is working. The approval queue is working. The cron trigger is not. Before debugging your content tool, check whether wp-cron is actually firing. The diagnostic takes five minutes with WP Crontrol, and the fix takes ten minutes with a system cron entry.
If you are running an automated content workflow, reliable scheduling is not optional. For a broader view of how automated publishing fits into a complete WordPress content strategy, see our guide on automated blog posts in WordPress and our breakdown of automatic SEO on WordPress.
Test Before You Trust the Schedule
Scheduled publishing is silent by design. WordPress does not email you when a post misses its schedule. It does not log a warning in the dashboard. The post just sits there in “Scheduled” status, waiting for a trigger that may never come. The only way to know your scheduling works is to test it explicitly: schedule a test post five minutes out, confirm it fires, and check WP Crontrol for missed events. If you find problems, replace the traffic-dependent trigger with a real system cron before you rely on it for your content calendar.
Try ClearPost free for 7 days. AI does the heavy lifting: keyword research, drafting, SEO optimization, and scheduling. You approve every post before it goes live. No auto-publishing, no agency overhead, cancel anytime. See what a reliable content pipeline looks like when the scheduling layer actually works.
Frequently Asked Questions
Why are my WordPress scheduled posts not publishing on time?
WordPress uses wp-cron, a pseudo-scheduler that only runs when someone visits your site. On low-traffic sites or sites with full-page caching, the cron trigger never fires and scheduled posts sit in Scheduled status until a visitor arrives. The fix is to disable the page-load trigger with DISABLE_WP_CRON and set up a real system cron job that hits wp-cron.php on a fixed schedule.
How does WordPress schedule posts internally?
When you schedule a post, WordPress calls wp_schedule_single_event() with a hook called publish_future_post and the post ID as an argument. That event is stored in the wp_options database table. When wp-cron fires, it checks for due events and executes publish_future_post, which changes the post status from future to publish.
Can plugin conflicts cause scheduled posts to fail?
Yes. If a plugin schedules cron events without checking wp_next_scheduled() first, it can create duplicate events that bloat the cron option and cause tasks to run multiple times. Argument type mismatches (integer vs string) also create ghost duplicates. The doing_cron transient lock can fail under race conditions when two cron triggers fire simultaneously.
How do I test if a scheduled post will publish in WordPress?
Install the free WP Crontrol plugin and go to Tools > Cron Events. Look for publish_future_post in the list. If it shows a red Missed label, your cron is not firing. You can also schedule a test post five minutes out and watch whether it publishes. With SSH access, run wp cron event list –due-now to see overdue events.
Should I disable WP-Cron and use a system cron instead?
If your site is low-traffic, uses full-page caching, or has scheduled posts that must publish on time, yes. Add define(‘DISABLE_WP_CRON’, true) to wp-config.php and configure a system cron job to hit wp-cron.php every 5 minutes. Never set the constant without also configuring the replacement, or all scheduled tasks will silently stop.