People start complaining that things aren’t working—renewals fail, reports don’t generate, scheduled emails never get sent. You bring in a developer who checks your site out and points out the problem: your Action Scheduler is on fire! It’s showing hundreds or thousands of retries, constantly re‑queuing jobs that never finish: bloating your database. You don’t even know what half those background tasks are, only that they’re killing your business. The dev can’t fix it. You need someone who understands WordPress internals well enough to calm this chaos and stop the endless loop.

So—what would I do?

First off I would disable WP‑Cron (DISABLE_WP_CRON=true) and schedule a system-level cron to run every 15 minutes to do the work. (More on this here—a similar situation to this one). Next I would look at your PHP configuration and see how hard I can push max_execution_time and memory_limit reasonably up to help Action Scheduler tasks finish. 

Then to the hard task: analyzing all the scheduled tasks going on in Action Scheduler and start examining logs to figure out why they are failing. It could be anything: a failing or slow API call, an overloaded database (I’ll do some database optimizations for that later), or just bad logic in the code that keeps failing. Either way I am likely looking at your site locally, running these jobs manually and using e.g. Xdebug + QCacheGrind (you can see how QCacheGrind works a little bit here) to find slow culprits. I’m actually likely running your site inside a cool tool I learned about this year called multipass, where I can replicate your server configuration more accurately to replicate the issue.

Now that we have all tasks deferred to a system-level cron, I’ll take silly—yes, plugins add silly clean-up tasks to Action Scheduler all the time, and they tank you site—and un-necessary schedules in AS and move them to a system-level cron that runs every week during off-peak traffic, we’ll pass ?late_actionscheduler to trigger those when we want them to run specifically. This ensures that AS is only running the necessary tasks needed for your business to work, and the rest later.

The last step will be to clean up the enormous log of failed and retried tasks in the database. Someone who knows what they’re doing has to do this, it can be a tangled mess to sort through if you don’t. I’d do this manually (backing it up, of course) and we’d have a clean slate. I would probably do a little more database optimization to ensure that it works well in the future, since I’m in there…

By the end of all this—hopefully—we’ve wrangled the Action Scheduler problem so it’s not continuing to be a huge mess. Honestly, we’d probably re-connect a month or so later to re-examine and probably do some final tweaks to make sure it stays wrangled!