Why you may need an external cron for AI Content Generator (and how to set it up)

WordPress’s built-in scheduling system relies on something called WP-Cron — a pseudo-cron that piggybacks on visitor traffic to fire scheduled events. On a high-traffic site it works invisibly. On a low-traffic blog, on a brand-new site, or on a publishing workflow that requires precise timing (news roundups at 06:00, daily briefings at 08:00), WP-Cron drifts: a campaign scheduled for 06:00 may not actually fire until the first visitor arrives, which could be hours later. An external cron solves this by feeding WP-Cron the traffic it lacks.

This tutorial explains exactly when you need an external cron for AI Content Generator, the three configuration options that work in practice, the verification steps to confirm the trigger is firing reliably, and the diagnostics to use when scheduled articles fail to appear at the expected time.

By the end you’ll have a publishing pipeline where every Articles per day / Time window / Fixed times setting configured in the Base data metabox actually translates into posts going live at the moment you expect — within seconds, not hours.

When you do (and don’t) need an external cron

WP-Cron is fine when your site gets a steady stream of visitors throughout the day. A blog with even 50 organic sessions per day distributed across the day will fire most scheduled events within minutes of their scheduled time. You don’t need an external cron for that scenario.

You do need an external cron in three situations. First, a brand-new blog with little traffic — WP-Cron can stay dormant for hours, missing your morning publishing window. Second, a site that needs precise timing (news, daily briefings) where being late by 30 minutes defeats the editorial purpose. Third, a high-volume site where you want multiple campaigns to fire on a predictable rhythm without depending on visitor luck.

The scheduling fields that depend on cron

Open any campaign and locate the Base data metabox. The fields that depend on the cron firing on time include Articles per day, Time window (start–end hour), Minimum gap between articles, Active days (Mon–Sun toggles), Fixed times (e.g. 09:00, 13:00, 18:00), Jitter ± minutes, Blackout dates and Catch up missed articles after pause.

Without a reliable cron trigger, the Time window and Fixed times become aspirational rather than enforced. The Jitter is calculated against the actual fire time, so if WP-Cron is late, your jitter compounds the delay rather than smoothing it.

Option A — Free external HTTP pinger

The simplest setup. You leave WP-Cron enabled and configure a free external service to hit https://your-site.com/wp-cron.php?doing_wp_cron=1 every 5 minutes. WordPress responds, fires any due events, and your AI Content Generator campaigns run on time.

• cron-job.org — free, dedicated to scheduled HTTP requests, can hit your URL every minute if needed. No credit card required.
• UptimeRobot — primarily an uptime monitor, but its 5-minute health check incidentally triggers WP-Cron and gives you free monitoring as a bonus.
• Cloudflare Worker Cron Trigger — if your site is behind Cloudflare, a 10-line Worker on a Cron Trigger schedule is the most reliable option.

Configure any one of them. Average delay between scheduled and actual fire drops from “hours” to under a minute.

Option B — Real OS cron via SSH

The cleaner solution when you have SSH access (DigitalOcean, AWS Lightsail, a managed VPS). Disable WP-Cron in wp-config.php:

define('DISABLE_WP_CRON', true);

Then add a Linux cron entry that runs every 5 minutes:

*/5 * * * * cd /var/www/your-site && wp cron event run --due-now >/dev/null 2>&1

Real OS cron beats HTTP pings on reliability: no chance of network hiccups dropping a trigger, no load on the public web server. The trade-off is the SSH access requirement, which excludes the cheapest shared-hosting tiers.

Option C — Managed hosting that handles cron for you

Several managed WordPress hosts (Kinsta, WP Engine, SiteGround on certain plans, Pressable) already replace WP-Cron with a real OS cron by default. If you’re on one of these hosts, there’s literally nothing to do — campaigns fire on time, period. Check your host’s documentation for “system cron” or “alternative WP-Cron”.

For an editorial calendar that publishes more than 30 articles per month, the time you’d spend wrangling external pingers on cheap shared hosting usually exceeds the price difference with managed hosting. Worth doing the math.

Step 4 — Verify the trigger is firing

After configuring any of the three options, you need to confirm it’s actually working. Two checks.

• Check WP-CLI cron event list — over SSH, run wp cron event list --due-now. It should return an empty list within a minute of any scheduled event. If due events accumulate, the cron isn’t firing.
• Check the external service’s logs — cron-job.org, UptimeRobot and Cloudflare all show recent request history. The history should be steady (every 5 minutes), with HTTP 200 responses (or HTTP 200 for cron-job.org, HTTP 204 for some). Anything else means the trigger broke.

A useful third check: schedule a one-off test campaign with Output status “Draft” and a Time window starting 5 minutes from now. Watch the AI Content Generator Logs panel. If a draft appears in that window, the trigger is healthy.

Avoid the most common configuration mistakes

• Pinging too often — every 1 minute is overkill and load on the database. Every 5 minutes is the sweet spot for AI Content Generator.
• Pinging the wrong URL — wp-cron.php, not wp-login.php. Add the query string ?doing_wp_cron=1 to skip the lock check that WP-Cron uses internally.
• Enabling both internal WP-Cron and OS cron — if you set DISABLE_WP_CRON to true, also remove any external pinger. Two triggers competing produces race conditions.
• Cloudflare cache eating the cron URL — exclude /wp-cron.php from your Cloudflare cache rules; otherwise Cloudflare returns a cached response and WordPress never wakes up.
• Timezone mismatch between WordPress and the cron service — both should agree on UTC, or both on your editorial timezone. Otherwise the “fire at 06:00” you configured locally fires at 06:00 server time, which may be 23:00 local time.

Troubleshooting drift after weeks of healthy operation

Even a healthy cron setup occasionally drifts. The most common causes after the first few weeks: a hosting migration that changed the server timezone; a WordPress core or plugin update that re-enabled WP-Cron alongside your external trigger; a Cloudflare rule update that started caching the cron URL; a payment failure on the external pinger that paused the schedule.

The fix is always the same: open the AI Content Generator Logs panel, look at the “last cron event” timestamp, compare against the current time. If the gap is larger than 10 minutes, your trigger broke. Walk through the verification steps above to identify which leg of the pipeline failed.

A sensible default setup

For a small or new site, pick Option A: leave WP-Cron enabled, add cron-job.org as the primary trigger every 5 minutes, configure UptimeRobot as a backup every 5 minutes but offset by 2.5 minutes. Total cost: zero. Reliability: very high.

Once the site grows past a few hundred articles per month, graduate to Option B (real OS cron) via your hosting panel. The transition is two lines (one in wp-config.php, one in crontab) and the cron behaviour becomes indistinguishable from any production-grade scheduled job.

You’re done

That’s the full external cron model: identify whether you need one (low-traffic, precise-timing, or high-volume sites do), pick Option A, B or C, configure the trigger to hit wp-cron.php every 5 minutes, verify via WP-CLI and the external service logs, watch the AI Content Generator Logs panel for drift.

From here every Base data scheduling field you configure (Articles per day, Time window, Fixed times, Jitter, Active days, Blackouts) translates directly into posts going live at the moment you intended. The editorial calendar becomes predictable rather than aspirational — which is the entire point of automated publishing.