Configuration settings for WPEngine?

Hi @vivalex

You’ve already ruled out the cron trigger itself, and WP Engine is right that it fires every minute. The 120-second average comes from how interval actions get their next run time.

If you scheduled this with as_schedule_recurring_action and a 60-second interval, here is what happens. When the action finishes, Action Scheduler creates the next one right then and sets it due at that moment plus 60 seconds. Your job takes about 5 seconds, so a run that starts on one cron tick makes the next action due 65 seconds later. The next tick comes 5 seconds too early, finds nothing due, and the action waits for the one after. Every second tick gets skipped, which lands you at 120 seconds. The “action created” line in the log is the creation moment, not the due time, so the action in your delayed example was due at 19:50:14 and ran 54 seconds late, not 114.

If you want it keyed to the clock instead, schedule it as a cron action:

as_schedule_cron_action( time(), '* * * * *', 'your_hook' );

The next run is always the next minute mark, no matter when the previous one finished. I tested both side by side on a local site with a 5-second job, and the queue runner ticked once a minute. The interval version ran every 121 seconds, the cron version ran once every minute. One tick in my test came up empty and gave a 179-second gap, which is where your 3-minute outliers most likely come from. The time limit filter won’t change any of this. It only caps how long one batch is allowed to run.

If you need tighter timing than one run per minute, the WP CLI runner is the route, triggered by a server cron if your host lets you set one up: https://actionscheduler.org/wp-cli/

Which function are you using to schedule the task at the moment? If it’s as_schedule_recurring_action, the swap above should be all it takes. Post what you see after the change, and we can go from there.

Hi @vivalex

No need to apologize, this is the right thing to check before your system depends on it.

if the job gets stuck and starts to run for 10 minutes instead of 5 seconds, is it possible that multiple jobs will run at the same time?

Not on its own. Action Scheduler only creates the next cron run after the current one finishes, the same as the interval version.

The exception is a run that lasts longer than 10 times the queue time limit, which is 10 minutes with your 60-second setting. Action Scheduler then treats it as dead and marks it failed. If your code schedules a new copy because nothing is pending, it starts while the old one keeps going, and the old one still schedules its own next run when it finishes. I reproduced that locally with a shortened limit and ended up with two schedules for one hook.

We are using the default, 1 queue. Does that ensure only one job will run at a time?

Yes, for everything short of that exception. The one queue is a limit for the whole site, not per hook. While your job runs, every other queue run sees it in progress and skips. I tested this with a 150-second job on a local site, and the next run started only after the job ended.

what setting should I put into place to ensure only one can run at a time?

Raise that limit above your longest possible run:

add_filter( 'action_scheduler_failure_period', function () {
	return 900;
} );

It only comes into play when a run can go past the 60-second cap, like with the WP-CLI runner from my earlier reply.

On WP Engine, keep one more thing in place. If PHP stops a WP Cron run at the 60-second limit you mentioned, Action Scheduler marks it failed and doesn’t create the next run, so the schedule stops. Can you please keep an as_has_scheduled_action( 'your_hook' ) check in front of your as_schedule_cron_action call on every load? That picks it back up after a killed run.