Action Scheduler 4.0 adds cleanup behavior that can remove old failed actions after a retention window. That is healthy for tables, but it means stores need a business report for failures that matter before evidence ages out.
Use this for WooCommerce stores where failed scheduled actions include payments, subscription renewals, webhooks, inventory syncs, customer emails, and conversion uploads.
Quick answer
Action Scheduler 4 Failed Actions Purge Report should be handled with a narrow evidence-first workflow: export failures, group by hook, assign owners, then verify the result before making broader changes.
What to check first
- Export failed actions by hook, group, age, attempts, claim, and last log message.
- Assign each failed group to a business owner: payments, fulfillment, marketing, support, or engineering.
- Separate harmless cleanup failures from revenue, customer, and reporting failures.
- Record which failed jobs should be retried, suppressed, fixed, or escalated to a vendor.
- Schedule a monthly queue report before old failures are purged.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Export failures | Export failed actions by hook, group, age, attempts, claim, and last log message. | Every high-impact failed action group has an owner and decision. |
| Group by hook | Assign each failed group to a business owner: payments, fulfillment, marketing, support, or engineering. | Retried jobs are tested for duplicate payments, emails, shipments, and uploads. |
| Assign owners | Separate harmless cleanup failures from revenue, customer, and reporting failures. | Harmless cleanup failures are documented so they do not waste support time. |
| Decide retry policy | Record which failed jobs should be retried, suppressed, fixed, or escalated to a vendor. | The next report runs before the cleanup window removes important history. |
Why this usually happens
- Queue tables grow until cleanup jobs remove history that no one reviewed.
- Support teams see symptoms such as missing emails, but engineers see only anonymous failed hooks.
- Retrying an old failed job can duplicate a payment, shipment, or conversion upload if idempotency is weak.
- A failed-action count without owner and impact creates noise rather than action.
Field notes
- Keep one compact owner report outside the Action Scheduler table for important failures.
- A failed hook name is not enough. Include example order IDs, lead IDs, or webhook IDs when privacy rules allow it.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp action-scheduler list --status=failed --format=json > failed-actions.json
jq 'group_by(.hook) | map({hook:.[0].hook,count:length,oldest:(map(.scheduled_date_gmt)|min)})' failed-actions.json
wp action-scheduler logs ACTION_ID
# Mark each group: retry, suppress, vendor, code fix, owner review.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Export failures
- Group by hook
- Assign owners
- Decide retry policy
- Schedule monthly report
What to tell the client or owner
Tell the owner which failed jobs affected revenue or customers, which were noise, and how future reports will catch them earlier.
Production verification checklist
- Every high-impact failed action group has an owner and decision.
- Retried jobs are tested for duplicate payments, emails, shipments, and uploads.
- Harmless cleanup failures are documented so they do not waste support time.
- The next report runs before the cleanup window removes important history.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, monitor WooCommerce background jobs.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references