Support » Fixing WordPress » Why does “missed schedule” even exist?

  • We run a very high traffic site (tens-of-thousands of page views per day), and 100% of the time any scheduled posts or pages result in almost immediately being converted to “missed schedule” status.

    If WordPress knows that a post missed its schedule, why doesn’t it just publish the post? Why did someone bother to code up the whole display of “missed schedule” instead of fixing whatever it is that gets something in that state?

    I realize there’s likely a very good answer to those questions, but for the life of me I can’t come up with it. Seems like a pretty easy query to write: if (post_scheduled_timestamp) < (current_timestamp) then let the post fly! 🙂

    Short of installing some 3rd party plugin, we’ve attempted to solve this in all the official ways, including scheduling a cron job on our server(s). Doesn’t matter. We even moved to a new server with a new build of apache, updated PHP, latest flavor of Centos 7, etc., no bueno. For some reason, posts “miss” their schedule 100% of the time.

    Any ideas for us before we all go bald tearing our hair out here? 🙂

Viewing 9 replies - 1 through 9 (of 9 total)
  • Moderator Steven Stern (sterndata)


    Forum Moderator

    >> We run a very high traffic site <<

    With lots of caching? It may be that the caching is keeping WP from seeing the access, which is necessary to publish pending posts.

    // edit //

    It seems you’re using Cloudflare. That may be the issue.

    What happens if you set up a “real” cron job that runs every 5 minutes:

    0 */5 * * * wget -O /dev/null --timeout=120 >/dev/null 2>&1

    Thread Starter macobserver


    Thanks, Steve! We are (currently) using Cloudflare, BUT… we also have our /etc/hosts file set to point at our server, not Cloudflare, for local requests. Command-line tests with curl confirm this is working, at least with curl. 🙂

    And… this issue predates us starting to use Cloudflare a month ago. But yes, we are using W3TC for some additional caching.

    We’ve had this cron job in place for years, with seemingly no impact:

    # 2017-06-21 WordPress Manual Cron
    */3	*	*	*	*	wget -q -O - "http://www.[example].com/wp-cron.php?doing_wp_cron" > /dev/null 2>&1

    I can certainly change that to yours, but it seems like we’re doing everything except setting =1 there. Would that potentially make the difference?

    Moderator Steven Stern (sterndata)


    Forum Moderator

    Maybe. I’m not sure.

    I use the triggered by an external Cron task.

    It’s also a good idea to establish a separate Cron task for any plugins that can be triggered that way. The documentation for those Cron triggered plugins will mention that in their documentation.

    Sometimes your site is just too busy for its own good at certain moments. Judiciously missing one Cron task when another needs to run is a good idea but hard to figure out at times. More horsepower helps in those cases also.

    And, when I schedule a post, I usually set the time but leave the absolute minute to whatever time it suggested during the scheduling. In other words, a post that is to be scheduled for midnight on a certain day winds up being scheduled for 0 – 9 minutes after that time. E.g., Midnight becomes something like midnight plus 6 minutes or so.

    • This reply was modified 3 years, 2 months ago by JNashHawkins.
    Thread Starter macobserver


    Thanks, @jnashhawkins — That plug-in is pretty old, so I’m not sure it’s something we’d want to be integrating into our environment.

    The weird part is that plugins like this even exist. I’m just not sure what WordPress is/isn’t doing to cause this problem to happen. Why would a command-line cron fail to trigger the very tasks that it’s supposed to trigger? Or have they already been put in “failed, never try again” state by the time that cronjob runs?

    And, if so, why?

    Anyone know?

    I’m very old… maybe you shouldn’t listen to me either! <Grin>

    The external cron triggers the WP Cron itself which then is tasked to run the current tasks in the queue. WP Cron was triggered by the PsuedoCron mechanism which is disabled by the plugin I recommended.

    The Crontask as @sterndata recommended triggers the WP Cron to run and still allows the PsuedoCron to run concurrently. I’m not real crazy about PsuedoCron running at the same time a second PsuedoCron or an actual Crontask is triggering WP Cron as it might setup a critical race condition in some subservient tasks.

    As to the plugin I recommended… I tend to grab any plugin that seems likely to work and then determine if it still suits my purposes regardless of age. That very plugin is still driving a lot of the sites I run and I figure if it ever breaks on me I’ll probably dive into it and fix it for my own use or try to talk the original authors into revisiting the same.

    The rest of the ‘why’ I’ll leave up to the ‘code scholars’ but I’ve suspected critical race conditions within WP Cron setup the queued tasks for failure. I don’t think I’ve ever seen an external Cron triggered plugin task not run except when the whole system or at least the app has died and then restarted.

    • This reply was modified 3 years, 2 months ago by JNashHawkins.
    Thread Starter macobserver


    I don’t think this is a race condition, given that we have this in our wp-config.php:

    /** Disable WP Cron */
    define('DISABLE_WP_CRON', true);

    In theory that should mean that wp-cron isn’t being triggered by visitors to the site, right?

    But, still, running with wget should work, no? Is there any way to look at a log and see why wp-cron fails?

    Again, I’m just curious why it would fail even after WordPress *knows* it’s failed (back “why display Missed Schedule instead of just publishing?”).

    Same issue on our side.

    We have a website with decent traffic, cron configured to ping the cron endpoint every minute and define('DISABLE_WP_CRON', true); yet posts fail to be published from time to time, and nothing gets logged. What’s weird to me is that the behavior is random. Like it happens once or twice a day on a total of 10 scheduled posts.

    We’ve read a bunch of articles out there that all point towards setting up a cron on the server but that doesn’t seem to work in a consistent fashion. Of course all plugin based solutions defeat the purpose because we want to avoid any non necessary load on the db etc.

    In our case, we are using a few plugins we know are slowing down the publishing of posts, like a Buffer plugin and an AMP plugin.
    Unfortunately, those are blind guesses and without logs there is little we can do.

    Has anyone managed to solved this problem?

    I couldn’t agree more with @macobserver, the current (actually not “current”, it has worked this strange way for ages) behavior doesn’t make any sense at all.

    I’ve had the Scheduled Post Trigger plugin installed on our WordPress for years, and it’s really a shame that we need that for such a simple core feature.

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Why does “missed schedule” even exist?’ is closed to new replies.