If you’ve ever scheduled an AI Content Generator campaign to publish at 06:00 and watched the first article actually appear at 09:42, you’ve met WordPress cron in person. The plugin does its job perfectly: it queues the campaign for the requested time. The problem is that WordPress itself doesn’t have a clock — it has a pseudo-cron called WP-Cron, and WP-Cron only runs when somebody visits the site. On a low-traffic blog at 06:00 on a Sunday morning, that “somebody” might not arrive until mid-morning, and your “06:00 publish” sits in the queue until then.
This tutorial explains exactly how WP-Cron works under the hood, why AI Content Generator depends on it for scheduled publishing, the three ways to make sure it actually fires on time, and the diagnostic tools the plugin offers when you suspect a campaign isn’t running when it should. By the end you’ll have a reliable scheduler that publishes within seconds of the time you set — even on a blog with zero visitors at 03:00.
The fix is not complicated. Once you understand the model, it takes ten minutes to bolt on an external trigger that hits /wp-cron.php every five minutes, and the problem disappears forever. The rest of this guide is about the model, the trade-offs, and how to verify the fix actually worked.
What WP-Cron actually is
WP-Cron is a PHP scheduler baked into WordPress core. It’s not a real cron in the operating-system sense. Real cron is a Linux process that wakes up every minute, looks at a list of scheduled tasks, runs whichever are due, then goes back to sleep. WP-Cron is different: it’s a piece of PHP code that runs only when a visitor’s request triggers WordPress. Every time a page loads on your site, WordPress checks the cron schedule, sees if anything is due, and if so, runs it asynchronously in the background.
This design has one huge advantage: it works on every WordPress hosting setup, even cheap shared hosting where you can’t add real cron jobs. It also has one huge disadvantage: a quiet site has no clock. A campaign scheduled for 03:00 only actually fires at the first visit after 03:00, which on a brand-new blog might be 09:00 the next morning.
How AI Content Generator uses the cron
When you save a campaign with Interval between generations = 60 (minutes) and a queue of 30 titles, AI Content Generator schedules a WP-Cron event called acg_run_campaign_{campaign_id} for every interval boundary. Every time the event fires, the plugin picks the next title from the queue, calls the AI provider, saves the resulting article as draft or publishes it, and re-schedules itself one interval later.
This works perfectly on a busy site with steady traffic: every minute someone visits, the cron checks, the event fires. On a low-traffic site you need to feed WP-Cron the traffic it lacks, which is what the next three steps are about.
Option A — Keep WP-Cron, add an external trigger
The simplest fix. You leave WP-Cron enabled and add an external service that pings https://your-site.com/wp-cron.php?doing_wp_cron=1 every 5 minutes. WordPress wakes up, sees due events, runs them — exactly as if a real visitor had hit the site.
Three good services for this, all free or very cheap. cron-job.org — a free service dedicated to scheduled HTTP requests, no account credit card required, can hit your URL every minute if you need it. UptimeRobot — primarily a monitoring service, but its 5-minute keepalive check incidentally triggers WP-Cron and gives you free uptime monitoring as a bonus. Cloudflare Workers Cron Triggers — if your site is behind Cloudflare you can write a 10-line worker that fires the request on a schedule, all in the Cloudflare dashboard.
Configure any one of them to GET your /wp-cron.php?doing_wp_cron=1 URL every 5 minutes. That’s it. Average delay between scheduled and actual fire drops from “hours” to under a minute.
Option B — Replace WP-Cron with real OS cron
If you have SSH access to your server (DigitalOcean, AWS Lightsail, a managed VPS), the cleaner solution is to disable WP-Cron entirely and add a real Linux cron job that runs WP-Cron on a fixed schedule. Add this line to wp-config.php:
define('DISABLE_WP_CRON', true);
Then add a Linux cron entry (crontab -e) that runs every 5 minutes:
*/5 * * * * cd /var/www/your-site && wp cron event run --due-now >/dev/null 2>&1
This route is more reliable than HTTP pings (no chance of network hiccups dropping a trigger) and adds zero load to your public web server. It’s the right choice for high-volume publishing workflows. The trade-off is the requirement for SSH access, which puts it out of reach for the cheapest shared-hosting tiers.
Option C — Managed hosting that handles cron for you
Some managed WordPress hosts (Kinsta, WP Engine, SiteGround on certain plans) already replace WP-Cron with a real OS cron in their default configuration. If you’re on one of these hosts, there is literally nothing to do — your campaigns fire on time, period. Check your host’s documentation; if they mention “system cron” or “alternative WP-Cron”, you’re already covered.
This is one of the underrated reasons to pay a bit more for managed hosting. The hidden cost of cheap shared hosting is the engineering time you spend wrangling WP-Cron; once that time costs more than the hosting difference, the calculation flips. For a serious editorial calendar this is almost always the most cost-effective path within a year.
Step 4 — Verify the trigger is firing
AI Content Generator includes a cron status panel in the Calendar view. It shows three things: whether WP-Cron is active in WordPress core, whether an external trigger has been detected pinging the site recently, and the per-campaign next-run timestamp.
Open AI Content Generator → Calendar and scroll to the bottom: you should see the cron status panel with three or four green dots and one summary metric — the average delay between scheduled and actual run over the last 24 hours. A healthy setup keeps that delay under 60 seconds. Anything climbing above 5 minutes means your trigger isn’t firing reliably; switch to a different service or check the cron service’s own logs.
Step 5 — Use the Logs panel when an article doesn’t appear
When a scheduled article doesn’t show up, the first place to look is AI Content Generator → Logs. Each cron run leaves a log entry with a status (success / failed / skipped) and a reason. Common reasons to find there:
- Cron didn’t fire — the timestamp of “last cron event” is more than an hour ago. Your external trigger is broken.
- Cron fired but skipped — the campaign queue was empty. Add titles.
- Cron fired but AI provider failed — the run attempted, the API returned an error (rate limit, billing, model deprecation). The log includes the exact error from the provider.
- Cron fired but plugin disabled — the campaign was paused or the AI Content Generator master switch in Settings is off.
Picking the right interval for your campaigns
Once you trust the cron is firing, the next question is what interval to pick for each campaign. AI Content Generator expresses the interval in minutes between generations, and the choice has more impact than people expect — both on publishing rhythm and on cost. Three rules of thumb cover most use cases.
- Daily publish at a fixed hour — use 1440 minutes. The campaign fires once per day at the time of the next scheduled run. Combine this with the editorial calendar to pin the exact publish hour (08:00 UK time is a strong default for English-language SEO content).
- Multi-post per day with steady spacing — divide 1440 by how many posts you want per day. Five posts per day means interval 288 (every 4h 48m); four posts per day means interval 360 (every 6 hours). Steady spacing produces a predictable RSS feed for subscribers and a clean rhythm in social-publishing tools that pull from the feed.
- News-style continuous publishing — interval 60 (hourly) or 30 (every 30 minutes). The plugin will keep firing as long as the queue has titles. Pair this with the News Mode panel that auto-replenishes titles from RSS sources, and you have a self-feeding pipeline.
Avoid the temptation of setting Interval 1 (“run every minute”). At that frequency you’ll hit AI-provider rate limits within the first hour and most of the cron triggers will fail with 429 errors. The minimum interval that runs cleanly on every provider tier is aro