Cron and background processing

How Aimogen Pro spreads long work across requests, why WP-Cron is the usual bottleneck, and how to make scheduled work reliable.

Aimogen Pro does work that cannot fit in one web request. Understanding how it spreads that work explains most performance problems.

The mechanisms#

WP-Cron for scheduling. The master aiomaticaction event fires every 15 minutes and runs rules that are due. See Cron events.

Single events for step-by-step work. Agents execute one step per aiomatic_agent_run_single event, each scheduling the next. That is why a 20-step agent never hits a PHP timeout — no single request does more than one step.

Jobs in Advanced Mode. Advanced Mode splits article generation into jobs so no request has to complete the whole article. Don't Use Jobs In The Advanced Mode Single Creators disables that, which is simpler to reason about and far more likely to time out.

Async posting in the editor. Use Async Posting Method dispatches editing work rather than doing it during the publish request, so publishing stays fast.

Deferred indexing. aiomatic_index_single_post indexes a post after publishing rather than during it.

WP-Cron is the bottleneck#

WP-Cron fires on page loads. On a low-traffic site, scheduled work runs late or not at all — and agents, which depend on a chain of single events, stall between steps.

// wp-config.php
define( 'DISABLE_WP_CRON', true );

*/5 * * * * curl -s "https://example.com/wp-cron.php?doing_wp_cron" > /dev/null 2>&1

Every minute if you use minute-level rule scheduling or run agents.

Verify under System & Logs › System Info, which reports whether WP-Cron is disabled and lists the plugin events with their next run times.

The run lock#

aiomatic_running_list prevents concurrent runs of the same rule. A run that dies leaves a stale entry and the rule is skipped forever after, silently.

The symptom is a rule that stops producing with nothing in the error log. The fix is System & Logs › Maintenance › Clear Running Rules List.

Stale entries are a symptom of runs dying, so if it happens repeatedly, look at your PHP limits.

PHP limits#

Three limits interact, and the smallest wins: PHP max_execution_time, the plugin request timeout, and the provider timeout.

For background work:

If a generation consistently dies at the same number of seconds, work out which limit that number is.

Choosing where work happens#

For anything large, WP-CLI is the right answer. It has no web server timeout, and the edit command cleans up memory every ten posts.

0 2 * * * cd /var/www/example.com && wp aimogen-run 0 3 >> /var/log/aimogen.log 2>&1

Throttling#

Two settings deliberately slow the plugin to stay inside provider quotas:

Raising them makes runs slower but avoids the retries that a 429 causes, which usually makes the run faster overall.

Monitoring#

System & Logs › Live AI Activity shows requests in real time — the fastest way to see whether a background run is progressing or stuck.

Activity Logs records rule executions and errors.

System Info confirms cron state.

Common problems#

Nothing runs on schedule. No real cron trigger. See Scheduled tasks do not run.

Runs start but do not finish. PHP timeout or memory. Check the limits, reduce batch sizes, use WP-CLI.

A rule stopped permanently. Stale run lock. Clear it.

Agents stall after one step. Cron is not firing the next single event.

Everything is slow during a run. Expected — provider calls dominate. Move the run to off-peak hours with system cron.

Related#

• Cron events
• Large workloads and scaling
• Scheduling and the posting cron