Blog fix: WordPress auto publish not working? A complete, reliable way to make scheduled posts go live on time

If your blog relies on scheduled posts and WordPress auto publish is not working, you are not alone. Missed releases are frustrating, especially when you planned content for a launch, a trip, or a campaign. This guide explains how scheduling works under the hood, what typically breaks, and the exact steps to restore dependable publishing—without guesswork. You will also find edge-case notes for Jetpack emails, Discourse integrations, and WordPress.com editors, all based on field experience and official documentation.

How WordPress actually schedules a blog post

What really triggers a scheduled release

On most installations, scheduled publishing depends on WP-Cron, WordPress’s task runner. Instead of a system-level cron that runs on a precise clock, WP-Cron is event-driven: every request to your site checks whether any tasks are due and, if yes, it tries to run them. This design avoids requiring shell access on shared hosts, but it also means low traffic can delay tasks. A scheduled post is saved with post_status=future and a timestamp; WP-Cron’s event (publish_future_post) is queued to switch it to publish when the site clock reaches that moment. If traffic is low at that exact time, or if loopback requests are blocked, it may slip. Some hosts disable wp-cron.php for performance, expecting you to configure a real cron that calls it at intervals. Others add aggressive caching or a firewall that filters the internal HTTP call WordPress makes to itself. Understanding these mechanics helps you diagnose issues quickly: if the system cannot tick at the right time, the job cannot run, so your article remains unpublished until the next successful tick or manual action.

Typical reasons scheduling stops

Several patterns recur when auto release fails: the site time zone is wrong (e.g., UTC instead of a city-based zone), the server time drifts, WP-Cron is disabled (DISABLE_WP_CRON is true) without a replacement system cron, HTTP loopbacks are blocked by security plugins or host firewalls, or there is too little traffic to trigger the event on time. Conflicts with plugins that hook into save_post can also interrupt the transition to publish—especially SEO, redirection, or custom-permalink tools. Page caching can interfere when it prevents loopback requests or returns stale responses to internal calls. A malformed permalink filter that appends stray characters may not break publication itself but can break related features like email click signatures or webhooks. Finally, a hosting control panel may have blocked external calls, TLS verification may fail, or Basic Auth might deny access to the REST API or loopbacks, leaving tasks in a pending state until a manual visit lets them fire.

A rapid triage to confirm scope

Before deep changes, confirm whether the problem is global or occasional. First, schedule a test post 5–10 minutes out, then visit the site in an incognito tab right at that time to trigger WP-Cron. If it goes live only after you load a page, your cron is not firing on schedule. Check Tools → Site Health → Status and Info for loopback test results, REST API accessibility, and scheduled events warnings. Visit a future-dated post and click Edit → switch the time to one minute ahead and wait on the Posts list screen to watch behavior. If nothing happens, install a diagnostics plugin like WP Crontrol to view scheduled events; look for publish_future_post due times in the past (missed schedule). If you are on managed hosting, ask support whether wp-cron.php is disabled by policy and whether outbound or loopback requests are filtered. Keep a short log of time stamps, plugins active, and any server messages. This narrows your fix to time settings, cron setup, or conflicts instead of random experimentation.

Restore accurate timing and cron execution

Align the clock and date settings

Open Settings → General and pick a city-based time zone (for example, Europe/Berlin or America/New_York) rather than a raw UTC offset. City zones auto-adjust for daylight saving time; fixed offsets do not. Verify the site date/time displayed there matches a trusted clock within a minute. Next, edit one upcoming piece and confirm its schedule is set in the future relative to the corrected time zone. If your server’s system clock is badly off, scheduled events can fire early or late; ask your host to confirm NTP synchronization. On multilingual or multisite setups, ensure each site’s time zone is configured—subsites inherit defaults but can be changed independently. Finally, verify that your php.ini or hosting control panel is not overriding the PHP time zone differently from WordPress (date.timezone). Mixed settings can produce confusion where the editor shows one time but server comparisons use another. Once the application and system agree on time, your calendar and the cron queue will refer to a single, consistent clock.

Confirm WP-Cron is allowed to run

Open wp-config.php and search for the line that defines DISABLE_WP_CRON. If it is set to true and you have not added a server-level cron, WordPress will never run scheduled tasks automatically. Either set it to false or add a real cron job that triggers wp-cron.php at a reliable interval. In Site Health, check that loopback requests succeed; a failure suggests that your server cannot call itself, which WP-Cron relies on. If a security plugin blocks localhost or your domain from issuing internal requests, add an allow rule. Some caching layers, including reverse proxies and CDN edge caches, may cache calls to wp-cron.php if misconfigured; exclude wp-cron.php from caching entirely. If the site is behind Basic Authentication or maintenance mode, WP-Cron will not pass the protection without credentials—disable protection or add exceptions while scheduling is critical. After changes, schedule a test post five minutes out and observe whether publish_future_post fires without you visiting the front end manually.

Add a real server cron for consistency

On shared or VPS hosting, add a system cron that curls wp-cron.php at regular intervals so jobs run even when there is no visitor traffic. In cPanel, create a cron job that runs every 5 minutes with a command similar to: curl -s https://example.com/wp-cron.php?doing_wp_cron=1 >/devull 2>&1. On servers where curl is not preferred, use wget with quiet and output to devull. If command-line PHP and WP-CLI are available, a more direct approach is wp cron event run –due-now executed by a system cron every 5 minutes; this avoids HTTP and caching layers entirely. Ensure your security policies allow these calls and that the URL is reachable over HTTPS without self-signed certificate errors. Managed hosts sometimes provide a panel toggle called “Alternate Cron” or a built-in scheduler—use their documented method instead of duplicating it. Once in place, your queue no longer depends on incidental traffic; timed events will process predictably, which is essential for a publication calendar or time-sensitive campaigns.

Remove conflicts from plugins, themes, and caches

Isolate compatibility issues safely

Conflicts often surface only at the moment a post transitions from future to publish. Use a controlled process to identify the culprit without taking your site offline. If available, activate the Health Check & Troubleshooting plugin and enable Troubleshooting Mode for your admin user; this lets you disable all plugins and switch to a default theme only for your session. Schedule a short test post and observe. If it publishes on time, re-enable plugins in small groups and retest until the delay or failure returns; the last change points to the source. In environments without that plugin, replicate the site on a staging domain, turn off object and page caches, switch to a default theme (Twenty Twenty-Four), and test. Do not overlook MU-plugins installed by hosts. Keep notes on exact versions; what worked yesterday may fail after an update. Once narrowed, check the vendor’s changelog and support threads for hooks related to save_post or publish_future_post and report your findings with precise timestamps to accelerate a fix.

Understand how caching can block internal calls

Full-page caches, reverse proxies, and CDNs accelerate delivery but can also interfere with WP-Cron and loopbacks. Ensure that the path /wp-cron.php is fully bypassed from caching at every layer: plugin (e.g., page cache), server (Nginx/Apache/Varnish), and CDN (edge rules). Some setups inadvertently cache 302 responses or return stale content when the site calls itself, causing cron invocations to be dropped. Object caches (Redis/Memcached) rarely cause missed schedules directly, but if they hold a corrupted cron array, events may not be recognized as due; flush the object cache once during diagnosis. Security plugins can block loopback user agents or localhost IPs; allow the WordPress user agent or the server’s own IP. If you use a maintenance mode or coming soon splash, confirm that it exempts wp-cron.php and loopbacks; otherwise, scheduled jobs pause until the mode is disabled. By systematically excluding only the necessary endpoints and keeping the rest cached, you preserve speed while restoring dependable task execution.

Notes from real cases: Jetpack, permalink filters, Discourse

Support threads show patterns worth checking early. Jetpack plan changes for commerce do not disable WordPress scheduling; missed releases are typically WP-Cron or conflicts, not billing. However, malformed permalinks can surface elsewhere: one site had an extra apostrophe appended by a custom filter, breaking email click signatures in subscriber messages; removing the stray character resolved the error. For Discourse integrations via the WP Discourse plugin, the auto-publish behavior is configurable from Publishing Options: Auto Publish defaults new posts to publish to Discourse, and Force Publish pushes all published entries to a default category. If content unexpectedly appears in WordPress from Discourse, that is not the intended feature path; check Discourse webhooks and any third-party automations (e.g., Zapier) that could post into WordPress. A user also reported that cleaning the database/cache with a maintenance tool resolved odd auto-post symptoms, indicating stale options or transient entries can contribute. Treat these as targeted checks: fix the permalink at the source, adjust Discourse settings or webhooks, and clear caches or transients where needed.

Inspect and recover missed or failed events

View, run, and repair the task queue

Install WP Crontrol to inspect scheduled events from Tools → Cron Events. Look for publish_future_post entries with a date/time in the past or a status that indicates a missed run. You can run an event immediately to test whether it completes, edit its schedule, or delete stuck duplicates. Query Monitor can surface HTTP API errors and loopback problems while you trigger a run; use it to capture error codes and response bodies. If your site uses Action Scheduler (bundled with WooCommerce and many plugins), check its queue at Tools → Scheduled Actions; a backlog there does not handle post publication but is a clue that the environment is generally struggling with background tasks. After you restore WP-Cron or a system cron, clear stale transients and reset any events that were marked as missed. If repeated failures target only one post, try a safe update: switch the post to draft, re-save, and re-schedule for a few minutes in the future; this regenerates the cron hook. Keep logs of each attempt so you can correlate a fix with a specific change rather than a coincidence.

Check loopbacks, REST, and site health signals

WordPress relies on loopback requests to call itself for certain tasks. In Tools → Site Health, review the Loopback requests test; failures can result from authentication prompts, IP rate limits, or firewall rules. The REST API endpoint at /wp-json/ should return a JSON object without a 401/403/500 error; locked-down environments with Basic Auth or security filters can inadvertently block this. On servers with ModSecurity or similar WAFs, rules may flag internal calls as suspicious; your host can whitelist the cron path or user agent. Review server error logs for entries around the scheduled time—transport errors like cURL error 28 (timeout) or 60 (SSL certificate) are common. If your domain recently moved to HTTPS, verify that your certificate chain is correct and that the server trusts it; internal requests fail if the stack does not accept its own certificate. Only when these health checks pass should you assume a deeper plugin or theme bug; otherwise, restore basic connectivity first to eliminate environmental blockers.

Safe stopgaps while you pursue the root cause

When publication must happen on schedule before a permanent fix is in place, a helper can bridge the gap. Plugins like Scheduled Post Trigger check for future posts on regular page loads and publish any that are past due. This is not a substitute for proper cron, but it reduces disruption during diagnosis. Some editors choose to set a system cron to run WP-CLI’s wp cron event run –due-now every minute during launches, then relax to every five minutes later for efficiency. For subscriber emails, if Jetpack or a newsletter tool depends on the on-time transition, consider manually publishing at the planned minute for critical posts. Document all temporary measures and remove them after resolving the core issue; layered workarounds can mask regressions. Finally, communicate with stakeholders—editors, marketers—about the adjusted process (for instance, “refresh the front page at the top of the hour”) to avoid last-minute surprises while you stabilize scheduling.

Platform nuances, integrations, and long editing sessions

WordPress.com editor sessions and browser behavior

On WordPress.com, some users have observed long editing sessions—especially with many images—where autosave stalls and the publish button greys out. In such cases, switching browsers (e.g., from Edge to Firefox or Chrome) resolved saves and final publication, while recovery of autosave drafts still worked regardless. Before major updates, clear cache and cookies, disable heavy extensions, and ensure the browser and OS are current. For very large compositions, drafting in a local editor or Google Docs and then finalizing in the block editor can reduce the chance of a session timeout. Note that re-shares to social networks may be suppressed if a post was already published once; this is by design. If your site shows a “Not Secure” warning, check for mixed content (HTTP images embedded in older entries); replacing or removing those eliminates the browser notice. These platform-specific observations do not change how scheduling works, but they can explain why a post appears blank or incomplete even after a status change appears to succeed in the dashboard.

Discourse links and unexpected cross-posting

If you connect to a Discourse forum via the WP Discourse plugin, two global options control cross-posting: Auto Publish marks the Discourse publish box on by default for new entries, and Force Publish sends all published entries to a default forum category. Those features aid outbound sharing from WordPress to Discourse. If you see content created in WordPress originating from the forum, that is not normal plugin behavior; re-check Discourse webhooks and any third-party automation like Zapier that might create posts. A user reported that cleaning the database and caches (for example, with WP-Optimize) cleared odd behaviors, suggesting state corruption can play a role. Also note a limitation: entries published through XML-RPC clients do not trigger Force Publish to Discourse in the default plugin implementation. If you need conditional rules—such as publishing to the forum only after a threshold of discussion or for select categories—build a small extension that hooks the plugin’s filters; the maintainers have indicated openness to adding hooks if a gap blocks that customization. Keep the rules simple to avoid tangled moderation workflows.

Email subscribers, signed links, and permalink hygiene

When subscriber emails include click-tracking or signed redirect links, even a tiny change to a URL can break the signature. A case in point: a site had an extra apostrophe appended to permalinks by a custom filter, which caused Jetpack’s tracking redirect to reject clicks as invalid signatures. The fix was not in the email service but in the permalink generator—remove the stray character so the generated URL matches the signed target exactly. If readers report broken links in digests while direct visits work, inspect the actual address captured in your emails; compare it to the canonical link shown in the editor and in the browser. Check for late filters on the_permalink or home_url that add or alter query strings and punctuation. Once you correct the root, flush caches and test a new post to confirm that the next message uses the repaired path. Paying attention to URL integrity also guards against SEO regressions; avoid ad-hoc changes to slugs on already published entries unless you maintain proper redirects.

Summary and next steps

Reliable scheduling in a blog depends on a correct clock, a functioning task runner, and a clean path for internal calls. Start by setting a city-based time zone and confirming that WordPress’s task runner is not disabled without a replacement. Add a server cron to invoke wp-cron.php or WP-CLI on a steady cadence. Isolate conflicts in a troubleshooting session, exclude wp-cron.php from caching, and unblock loopbacks and the REST API. Use WP Crontrol to inspect and run due items, and keep temporary helpers only as a bridge. For integrations, verify Discourse settings and webhooks, and maintain clean permalinks so subscriber email signatures remain valid. If you would like a checklist to share with your hosting provider or developer, focus on these items: enable cron, add a 5‑minute system cron, bypass caching for wp-cron.php, allow loopbacks, verify TLS, and confirm no plugin alters the publish transition. Helpful references: developer.wordpress.org/plugins/cron, wordpress.org/support for missed schedule threads, and meta.discourse.org for WP Discourse behavior. With these steps, scheduled posts should publish exactly when you plan them—no manual nudges required.