action-scheduler-triage

Hundreds of failures, one row at a time

Action Scheduler keeps every failed background action with its log, and a busy store can collect hundreds: a CRM sync that hit a rate limit, receipts that stopped after an SMTP password change, a payment capture that timed out. The admin screen shows them one row at a time. action-scheduler-triage reads the failed actions you export with WP-CLI, groups them, and sorts the groups into those that are safe to run again unchanged, those that need a fix first, and those a person should look at.

The tool only reads. It reads JSON files and prints a report; it never runs WP-CLI, never connects to your database and never retries anything itself.

Groups by hook and error

Grouping is done in code. The error is the failure message in the action's log, and Action Scheduler's own lines ("action created", "action started via WP Cron") are skipped. Ids, amounts, dates, times, numbers, hashes and email addresses in the error become placeholders, so two failures that differ only in the order number and the amount share a group, while error codes and HTTP status codes (cURL error 28, HTTP 429) stay, because they tell causes apart. Both wordings Action Scheduler has used for an action that ran past its time limit read as one error.

What is asked about each group

Jev, TypeSafe AI's System One model, answers typed questions with probabilities and writes no text. Each group gets three questions:

• the cause, one of seven: transient network or timeout, rate limited, credentials or auth, invalid data, code error, missing plugin or callback, other;
• a yes or no: is it safe to run these actions again as they are, with the same arguments and without changing code, data or settings first? Safe means the failure came from a temporary condition that has likely passed, and a rerun would not repeat a payment, a refund, an email or an order that may already have happened;
• the urgency, on four levels: can wait, routine, soon, now.

Code then puts each group in one list, with a threshold of 0.8 unless you set another. A group is safe to retry only when the cause is a timeout or a rate limit with confidence at or above the threshold and the yes is at or above it too. It needs a fix first when the answer is a confident no and the cause is confident. Everything else goes to review, including a "safe" answer for a cause that a rerun cannot fix, where the two answers disagree.

Retry commands you run yourself

Action Scheduler does not run a failed action again: its runner skips any action that is not pending, so wp action-scheduler action run <id> does nothing for a failed one. Running the work again means a new action with the same hook, arguments and group, and that is what the report prints for each action in a group judged safe to retry.

The arguments are copied exactly as exported, because a masked value would run the action with the wrong data, so treat the report like the export: it can hold customer data. Commands are quoted for a POSIX shell, recurring actions get no commands (their next scheduled run repeats the work), and an action whose arguments cannot be copied exactly is left out with the reason. Past-due pending actions are listed per hook with wp action-scheduler run --hooks=<hook> and are never sent to Jev: they have not failed, and the usual reason they wait is a queue problem.

What Jev sees, and what it does not

For each failed group, a request carries the hook name, the group names, the cleaned error (at most 500 characters), whether the actions are recurring, how often the group failed in words, whether the arguments differ, the names and value types of one action's arguments (never the values), and whether Action Scheduler stopped rescheduling it. Action IDs, argument values, dates, exact counts and the past-due actions are never sent, and --dry-run --json prints every request body first.

Limits

• It sees the export and nothing else. It cannot tell whether a remote service is back, whether a payment went through, or whether a plugin is active now. Read each group before you run its commands.
• Grouping can merge two problems that print the same message from the same hook, or split one whose messages differ in words.
• Error text can hold words a customer or a remote service wrote, and such text can move an answer.
• Action Scheduler's own log lines are read in English; on a site in another language the last log line is taken as the error.
• Since Action Scheduler 4.0.0, failed actions are deleted after three months by default, so an export holds at most that much history.
• The example export in the repository is synthetic (87 failed actions in 12 groups) and runs with hand-written answers in place of Jev, so its probabilities are illustrations, not results from a live run.

Export and run

The export needs WP-CLI and Action Scheduler 3.9.1 or later, the release that added the wp action-scheduler action commands. Name args and log_entries in --fields (the defaults leave both out) and set --per_page, which otherwise returns five actions.

wp action-scheduler action list --status=failed --orderby=modified --order=DESC --per_page=1000 --fields=id,hook,status,group,recurring,scheduled_date,args,log_entries --format=json > failed-actions.json
npm install -g github:hamzaahmadaslam/action-scheduler-triage
action-scheduler-triage failed-actions.json --dry-run

It needs Node.js 20 or later and installs no other packages.