Blog WordPress auto publish not working? Definitive, source‑backed fixes for scheduled posts and Discourse

If your blog relies on WordPress to auto publish at a set time, a missed schedule can derail campaigns, newsletters, and social shares. This guide explains exactly how WordPress scheduling works, why it breaks, how to fix it step by step, and how Discourse, Zapier, and other automations can complicate the picture. All steps are reproducible and based on WordPress and plugin documentation.

How WordPress auto publishing actually works for a blog

What “auto publish” means in WordPress core

In WordPress core, scheduling uses WP‑Cron, an internal task runner that fires when someone (or something) loads a page on your site. When you set a future publish time, WordPress creates a cron event (publish_future_post) to transition the post status from scheduled to published at that timestamp. Two details matter in production: 1) WP‑Cron is traffic‑triggered by default, so a low‑traffic blog may not “wake up” at the exact minute; 2) time is evaluated against your site timezone in Settings → General, not necessarily server UTC. If the auto publish job misses its window (for example, due to blocked loopback requests, caching, or an overloaded server), WordPress can leave the post in “missed schedule.” Tools like Site Health (Tools → Site Health) will flag loopback issues, and plugins such as WP Crontrol can reveal whether publish_future_post is scheduled, overdue, or failing. Understanding this internal mechanism keeps you from chasing unrelated causes like analytics plugins.

How WordPress ↔ Discourse publishing really behaves

Many teams pair their blog with a Discourse community. The official WP Discourse plugin offers two options: Auto Publish (pre‑checks a per‑post box so publishing to Discourse is the default) and Force Publish (sends every published post to a default Discourse category). Crucially, these settings control WordPress → Discourse, not the reverse. The plugin does not create WordPress posts from Discourse topics. If you observe posts or media appearing in WordPress seemingly “from Discourse,” look for third‑party automations (Zapier, webhooks) or custom code. Also note a documented limitation: posts published via XML‑RPC (e.g., legacy apps) may not trigger Discourse publishing. This distinction prevents misdiagnosis when you think “auto publish not working” but the real path is different.

Typical symptoms and what they imply

You may see one of several patterns: 1) a scheduled post remains “missed schedule,” implying WP‑Cron never executed or failed; 2) the post publishes late, which suggests traffic‑triggered cron lag; 3) email or push notifications contain broken links, indicating permalink generation or filtering issues rather than scheduling; 4) unexpected WordPress drafts or media appear, hinting at external automations submitting content; 5) Discourse topics aren’t created when a blog post is published, pointing to plugin configuration, XML‑RPC limitations, or API failures. Recognizing which pattern you’re facing narrows the fix: cron and loopback for missed/late schedules; permalink and plugin filters for broken links; webhook and audit logs for stray content; Discourse plugin options and logs for cross‑posting. Start by capturing the exact symptom and timestamp, then match it to the relevant diagnostic path below.

10‑minute triage: fast checks that solve most cases

Timezone, future time, and visibility sanity checks

First, verify the basics that frequently save a blog from longer downtime. In Settings → General, ensure “Timezone” matches your editorial workflow (city or offset) and confirm scheduled times are in that timezone. Edit the scheduled post and confirm it’s truly in the future, public, and not password‑protected or pending review (which would block publishing). If your hosting uses object caching or full‑page caching with long TTLs, reduce TTL on /wp-cron.php or bypass caching for that endpoint. Confirm your server time via phpinfo() or WP‑CLI (wp eval ‘echo date(“c”);’) if inconsistencies are suspected. Finally, if you recently migrated, re‑save permalinks (Settings → Permalinks → Save Changes) to clear rewrite anomalies that sometimes cascade into scheduling glitches.

Loopback requests and WP‑Cron status

Go to Tools → Site Health → Status. If you see loopback request failures, WP‑Cron may not be able to call itself to run tasks. Click “Passed/Recommended improvements” for specifics. Next, install WP Crontrol to inspect Tools → Cron Events and confirm publish_future_post is scheduled for your item. If you see missed_schedule items, run them manually from WP Crontrol’s UI. Using WP‑CLI, run wp cron event list and wp cron event run –due-now to execute overdue tasks. If running them manually works, you likely have loopback or traffic issues and can move to the “real cron” fix below. If events are absent altogether, the post may never have saved a schedule correctly—re‑schedule and update the post to regenerate the event.

Plugin/theme conflicts and caching/CDN constraints

Conflicts often present as “blog WordPress auto publish not working” after a recent update. Temporarily switch to a default theme (Twenty Twenty‑Four/‑Five) and disable all non‑essential plugins. Re‑test scheduling. If it works, re‑enable items in batches to isolate the culprit. Pay attention to: 1) security plugins that block loopback or wp‑cron.php; 2) performance plugins that cache or preload cron endpoints; 3) custom permalink filters adding characters that break signed URLs in email; 4) plugins intercepting transition_post_status hooks. For CDNs and WAFs, whitelist wp‑cron.php and admin‑ajax.php, and ensure the origin isn’t rate‑limited (429/403) during cron calls. Note that changes to Jetpack Stats or plan level do not affect core scheduling, per Jetpack’s team statements; treat Jetpack as adjacent unless a module specifically intercepts publish hooks.

Reliable fixes for scheduled posts that refuse to publish

Replace traffic‑triggered WP‑Cron with a real server cron

On busy or quiet sites alike, a system cron is more predictable. Step 1: In wp-config.php, set define(‘DISABLE_WP_CRON’, true); to prevent traffic from firing cron. Step 2: Add a server cron job (every minute or five minutes) to call WP‑CLI or the cron endpoint. Example (crontab): */5 * * * * php /path/to/site/wp-cron.php >/devull 2>&1. Alternatively, with WP‑CLI: */5 * * * * /usr/bin/wp cron event run –due-now –path=/path/to/site >/devull 2>&1. Confirm it runs by watching wp cron event list before and after the minute rolls over. Hosting panels often provide a cron UI; on managed WordPress hosts, consult their docs for the supported pattern. Moving to system cron eliminates the dependency on visitor traffic and resolves the vast majority of “missed schedule” incidents for a content calendar–driven blog.

Fix server‑level blockers: loopback, auth, and WAF

If Site Health reports loopback problems, address them directly. Common blockers include HTTP Basic Auth on production, maintenance plugins adding auth walls, or a reverse proxy needing proper X‑Forwarded‑For/Host headers. Ensure the site can request its own wp-cron.php without credentials. On WAFs or CDNs, allowlist the cron path and ensure no bot mitigation is triggering on your server IP. Check error logs for 401/403/429 responses around scheduled times. On container or auto‑scaled setups, ensure all nodes share the same DB/object cache and that only one node runs cron to avoid lock contention. If your host disables loopback for security, their knowledge base typically includes a recommended cron configuration—apply that and keep DISABLE_WP_CRON true to avoid double‑fires.

Repair missed events and clean transients/database state

Sometimes the schedule is set, but stale transients or option locks prevent execution. Use WP Crontrol to delete stuck events and re‑schedule by updating the post date. Clear object cache (Redis/Memcached) if present. Database cleanup tools like WP‑Optimize can purge transient/options bloat; one Discourse user reported that cleaning resolved phantom auto‑publishes and oddities. Programmatically, you can re‑queue overdue posts with a small mu‑plugin: on init, query posts with post_status=future and post_date_gmt < now, and call wp_publish_post for each. Remove the code after repair to avoid interfering with normal flows. Finally, confirm your timezone and site URL settings are correct post‑cleanup, then test with a throwaway post scheduled 10 minutes ahead to verify that new events run on time.

Cross‑posting with Discourse, Zapier, and other automations

Configure WP Discourse correctly and test the publishing path

In the WP Discourse settings, choose between Auto Publish (default the per‑post checkbox to on) and Force Publish (send every published post to a default category). Test with a fresh post: publish and confirm a topic is created in Discourse. Remember that XML‑RPC published posts are excluded from Force Publish. If your expectation is Discourse → WordPress, note that the plugin does not implement that flow. Seeing content arrive in WordPress “from Discourse” usually indicates another integration at work. Keep logs on: enable WordPress debug logging (WP_DEBUG_LOG) and check the Discourse side for request logs to pinpoint if/when the API call occurs. Document the exact trigger that should create a topic or comment thread to validate behavior against the plugin’s documented scope.

Identify stray webhooks and Zapier recipes that create posts

If drafts or media appear in WordPress without an editor’s action, audit automations. In Zapier, review Zaps that watch Discourse topics or categories and then call WordPress “Create Post” or “Upload Media.” In WordPress, inspect users’ application passwords and tokens that could authorize REST API writes. Also check any custom webhooks configured in Discourse Admin → Integrations. Disable suspected automations for 24–48 hours and observe whether unexpected content stops. Re‑enable one by one. This isolation step often surfaces a well‑intended workflow that was forgotten after experiments, explaining why a blog shows unexpected posts while you think “blog WordPress auto publish not working.”

Fix partial or media‑only publishes into WordPress

Cases where only images appear without a corresponding post point to an automation sending attachments to the WordPress REST API or to a browser extension pushing media. Review server access logs filtered by POST requests to /wp-json/wp/v2/media and /xmlrpc.php at the incident time. Ensure the requesting IPs map to your automation platform if expected; otherwise, rotate application passwords and revoke tokens. If Zapier or similar is intended, modify the recipe to first create a post, capture its ID, then upload media and set featured_media to that ID. Where Discourse webhooks are involved, validate payload mappings and ensure you are not firing a media upload action on image embeds alone. After corrections, test with a private WordPress staging site so your public blog remains clean during verification.

Edge cases that keep teams debugging for days

Permalink manipulation that breaks notification links

A subtle issue arises when a filter adds stray characters to permalinks. Teams have reported subscriber emails where clicking a post returns an invalid signature error; inspecting the URL shows an extra quote at the end. This is not a scheduling fault; it is a permalink generation bug introduced by a theme or plugin filter (e.g., filtering the_permalink). To diagnose, disable plugins, switch themes, and inspect the raw permalink in the editor and on the front end. Re‑save permalinks and remove custom filters that alter URLs. Once the permalink is clean, notification signatures validate again and users reach the correct post. Keep this in mind if scheduling “works,” but traffic and analytics drop because readers never land on the right page.

Multilingual, CPTs, headless, and static caching interactions

Multilingual plugins, custom post types, headless builds, and static caches add complexity. For CPTs, ensure they support ‘future’ in register_post_type and are included in cron transitions. In multilingual setups, confirm the scheduled item exists and is published in the correct language domain or path, and that redirections do not hide it. For headless sites or static generators, publishing in WordPress must also trigger a build or purge to expose the post; otherwise, observers think it “didn’t publish.” On static caches, set short TTLs or purge rules for newly published URLs. For sites using pre_get_posts to filter archives, confirm scheduled posts appear as intended post‑publish and are not being excluded by custom conditions.

Security hardening, rate limits, and cron locking

Security plugins may disable loopback, block wp-cron.php, or require nonces that break cron calls. WAFs sometimes rate‑limit the origin, returning 429s to the cron runner. Object cache locks (cron_lock) can become stuck during heavy traffic, preventing new cron runs. Monitor server logs and WP_DEBUG_LOG around the schedule time. If you suspect locks, clear object cache and manually run due events. On scaled infrastructure, consider a single authoritative cron runner with DISABLE_WP_CRON enabled on all nodes and a dedicated system job on one node. Finally, if your team uses basic auth on staging, remember that cron cannot authenticate unless configured; either disable auth for wp-cron.php on staging or inject the credentials into the curl command in your crontab.

Summary and next steps

When auto publishing fails, map the symptom first, then proceed in order: confirm timezone and visibility, check Site Health loopback, inspect and run cron with WP Crontrol or WP‑CLI, switch to a system cron, and clear transients or locks. Treat Discourse and other automations as separate flows: WP Discourse moves WordPress → Discourse, not the reverse; unexpected WordPress posts or media usually come from webhooks or Zapier. Address permalink filters if notification links break. After each fix, validate with a low‑stakes scheduled post within 10–15 minutes to confirm reliability. If you run a business blog and prefer hands‑on remediation, consider engaging your host for a server cron and loopback allowlisting, or work with a developer to audit automations and REST permissions.

Selected references for deeper reading: WordPress Cron Handbook • WP Crontrol • WP Discourse auto publishing behavior • Community thread on missed schedules and Jetpack clarification • Discussion on unexpected WordPress content and DB cleanup.