WordPress doesn't use real cron—here's when posts miss their slot
The hum of a server rack at 3am, fans spinning while everyone sleeps, a post that was supposed to go live at 6:00 sitting idle in the database—no error, no log entry, just silence.
WordPress scheduling doesn’t run on the clock—it waits for traffic
Your posts won’t publish on time unless someone visits your site to trigger the fake cron system.
WordPress doesn’t schedule posts with server cron. It uses WP-Cron, a PHP script that checks for overdue tasks every time a page loads—any page, by any visitor. If your site gets steady traffic, posts publish close to their scheduled time. If you schedule a post for 6am and nobody visits until 9am, your post goes live at 9am. No traffic, no trigger, no post.
The system fails predictably in three scenarios: low-traffic sites where hours pass between page views, high-traffic sites where aggressive caching prevents WP-Cron from firing, and any site behind a page cache that serves static HTML without touching PHP. You’ll also miss slots if a long-running task—like a backup plugin or an image optimizer—blocks the queue. WP-Cron is single-threaded; one slow job stalls everything behind it.
The fix is server-level cron or a dedicated service that hits wp-cron.php every few minutes, decoupling publication from visitor activity. You can disable WP-Cron in wp-config.php and add a real cron job, or use a monitoring service that pings the endpoint. Either way, you stop depending on traffic to publish content. The tradeoff is minimal: you’re trading unpredictability for two lines of configuration and a cron entry that runs whether or not anyone’s reading.
RELATED FAILURE MODE
Scheduled post APIs fail silently—here’s what gets dropped
Social schedulers and cross-posting tools queue content days in advance, then hit API rate limits, token expirations, or webhook failures at publish time. Most don’t send alerts; the post simply never appears. You check your dashboard three hours later and find a blank slot where a LinkedIn update should have been. The failure is invisible until you notice the missing engagement. If you’re scheduling to multiple platforms or auto-publishing WordPress content to social, you need a system that logs every attempt and flags drops in real time—not a dashboard you have to check manually.
TACTIC
Cache expiration headers control what browsers store—and for how long
WordPress sets default cache headers that tell browsers and CDNs how long to keep a copy of your page. If you publish an update but readers still see the old version, it’s because their browser cached the page for an hour—or a week—based on the Cache-Control header your server sent. You can override expiration times in your caching plugin or CDN settings, but most operators never check what’s actually being sent. Short TTLs mean fresh content; long TTLs mean faster repeat visits but stale posts when you edit. The tradeoff matters most when you’re correcting errors or adding time-sensitive CTAs after publication.
WORTH READING
Zapier task history vanishes after 14 days—archive what matters
Zapier keeps task logs for two weeks, then deletes them. If you’re using Zaps to sync subscriber data, trigger welcome sequences, or log form submissions, that history disappears before you’ve had time to audit it. You won’t know which tasks failed last month, which leads were skipped, or whether a webhook fired twice. If you need an audit trail—for compliance, debugging, or attribution—you have to pipe task data into a spreadsheet, database, or logging service before the retention window closes. Most operators assume the logs persist indefinitely; they don’t, and there’s no extension option on free or mid-tier plans.
Know someone who would like this? Forward today’s email—every operator we reach is one closer to running an online business with a little less friction.