Asyncra Queue Triage for Action Scheduler
The checks at the top and the failed actions grouped by hook and error, each with a label and what to check next.
Action Scheduler is the background job queue inside WooCommerce and many other plugins. When it goes wrong, its own screen lists the actions one row at a time, and the notice “past-due actions found; something may be wrong” does not say what is wrong.
Asyncra Queue Triage adds one screen under Tools > Queue Triage that answers the questions a store owner or a developer asks first:
- Why are actions failing? The newest failed actions (500 by default) are grouped by hook and by their error, with ids, dates, amounts, quoted values, email addresses and server paths taken out. 800 failures that differ only in an order number read as one group.
- What should I do about each group? Each group gets a label from fixed rules: Fix first (a missing callback, a PHP error, rejected credentials, a deleted record), Retry candidate, check first (timeouts, rate limits, remote server errors) or Review. Each label comes with what the error usually means and what to check next.
- Is the queue running? Past-due actions, how late the oldest one is, and the ten hooks with the most. Whether WP-Cron is disabled, when the queue’s cron event is due, and when anything last ran.
- Is anything stuck? Actions in progress for more than five minutes, and claims left behind by a run that stopped part-way.
- Are the tables growing? Rows and size of each Action Scheduler table, the retention periods in effect on this site, and whether cleanup keeps up with them.
- Which copy of Action Scheduler is running? The version in use, the plugin it comes from, and every copy other plugins bundle.
It also adds two Site Health tests (is the queue running on time, are actions failing), a section in Site Health Info, a report you can paste into a support ticket, and a WP-CLI command.
What it never does
- It never runs, retries, cancels, edits or deletes an action, and it never writes to the database. It has no settings and stores nothing.
- It makes no external requests and collects no data. Nothing leaves your site.
- It has no upsell, no ads and no notices outside its own screen.
Why “retry candidate” and not “safe to retry”
The rules read the error text and the hook name, nothing else. They cannot see whether a payment went through before a timeout, or whether a remote service already received a request. So no group is ever called safe, and hooks whose names suggest payments, renewals, refunds, receipts, emails or webhooks never get the retry label at all.
Works with
Anything that uses Action Scheduler with its own database tables, such as WooCommerce, the Action Scheduler plugin and the many plugins that bundle it. Tested with Action Scheduler 3.9.2, 4.1.0 (inside WooCommerce 11.2.1) and 4.2.0. If no active plugin loads Action Scheduler, the screen still reads the tables that remain and says so.
WP-CLI
wp queue-triage report prints the support report. `--format=groups` prints the failure groups as a table, `--format=json` prints everything, and `--sample=2000` reads more failed actions.
Source code
Development happens on GitHub: hamzaahmadaslam/asyncra-queue-triage. Issues and pull requests are welcome there.