Scheduled tasks do not run

Why Aimogen Pro rules, editing and agents do not run on schedule, and how to make WP-Cron reliable.

Symptoms#

Manual runs work. Scheduled runs do not, or happen hours late. Agents start and then stall.

If manual runs also fail, this is not your problem — see No posts are being created.

Cause 1: no real cron trigger#

By far the most common.

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

Check: System & Logs › System Info, the WP-Cron running line.

Fix:

// 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 scheduling or run agents.

If you cannot add a system cron job, most hosts offer a cron manager, and external services can hit the URL on a schedule.

Cause 2: a stale run lock#

The one that looks like nothing at all.

aiomatic_running_list prevents concurrent runs of the same rule. If a run dies — PHP fatal, timeout, host process kill — the entry is left behind and the rule is skipped forever after, with nothing logged.

Symptom: a rule that stopped producing on a specific date, with a clean error log.

Check: System & Logs › Maintenance › Rules Currently Running.

Fix: Clear Running Rules List.

If it recurs, runs are dying. Look at PHP limits — see Cron and background processing.

Cause 3: the rule is inactive#

Active must be on. Inactive rules are skipped by the scheduler but still run manually, which produces exactly this symptom.

Cause 4: the interval has not elapsed#

The master aiomaticaction event fires every 15 minutes and runs rules whose own interval has elapsed. A rule with Schedule = 24 runs once a day, not once per master event.

Check the last-run time on the rule and add the interval.

Cause 5: the minute/hour switcher changed the units#

If the CodeRevolution Schedule Minute/Hour Switcher plugin is active, rule Schedule values are interpreted as minutes rather than hours.

Activating it turns a daily rule (24) into one that runs every 24 minutes. Deactivating it does the reverse — a rule set to 30 for half-hourly becomes 30-hourly.

Check whether the plugin is active, and review every rule interval after changing it.

Cause 6: the day-of-week filter#

Do Not Run This Rule On The Following Days Of The Week silently skips selected days.

Cause 7: agent-specific stalls#

Agents dispatch each step through aiomatic_agent_run_single. If cron is unreliable, the agent runs one step and stops.

aiomatic_agents_watchdog runs every 10 minutes looking for stuck agents, and aiomatic_agent_recover attempts recovery — but both are themselves cron events, so they need cron working too.

Check the agent execution log for the last successful step, and System Info for cron state.

Cause 8: events not registered#

Some events are only scheduled when their feature is enabled. aiomaticeditaction exists only when automatic editing is on; aiomaticactionclear only when logging and auto-clearing are on.

Check the event list in System Info, or from WP-CLI:

wp cron event list --fields=hook,next_run_relative,recurrence | grep aiomatic

Cause 9: another plugin cleared the schedule#

Some optimisation and security plugins clear cron events. Reactivating Aimogen Pro re-registers them.

Verifying a fix#

# Confirm the event is scheduled
wp cron event list | grep aiomaticaction

# Fire it manually
wp cron event run aiomaticaction

Then check System & Logs › Activity Logs for the execution entry.

Bypassing WP-Cron entirely#

For important scheduled generation, drive rules directly from system cron with WP-CLI:

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

This has no web timeout, no WP-Cron dependency and precise timing. For anything you actually depend on, it is the more reliable arrangement.

Related#

• Cron events
• Scheduling and the posting cron
• Cron and background processing