WooCommerce teams often alert on failed count or total pending actions. A low-volume queue can still strand one subscription renewal, stock sync, webhook, email, or cleanup task for hours. An oldest-action service-level objective makes age, hook class, customer impact, claim ownership, retry state, and deployment drain visible before a backlog becomes a support issue.
Use this for WooCommerce stores, subscription sites, fulfillment teams, payment integrations, agencies, hosts, and any deployment that depends on Action Scheduler workers.
Quick answer
Define age objectives by hook class and business impact rather than one global threshold. Export pending, in-progress, failed, and canceled actions with scheduled time, claim, runner, package version, attempts, last error, group, order or fixture ID, and customer outcome. Track oldest age, age percentiles, completion rate, retry rate, claim duration, and error-budget burn. During deployment, stop new claims, drain bounded work, replace workers, resume, and reconcile each synthetic action exactly once.
What to check first
- Inventory runners, schedules, hook groups, business owners, package versions, concurrency, and maximum expected durations.
- Define oldest-age and completion objectives for payment, email, stock, webhook, subscription, import, and cleanup classes.
- Capture pending, claimed, completed, failed, canceled, retry, and long-running fixtures with stable IDs.
- Alert on oldest age, percentile age, claim duration, retry slope, failure rate, worker heartbeat, and business outcome lag.
- Run a deployment drain and recovery test with old workers, new workers, interruption, duplicate delivery, and idempotency checks.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Classify hooks by user impact and expected duration. | Inventory runners, schedules, hook groups, business owners, package versions, concurrency, and maximum expected durations. | Critical oldest-action age and burn rate are visible by hook class. |
| Set age, completion, retry, and claim objectives with named owners. | Define oldest-age and completion objectives for payment, email, stock, webhook, subscription, import, and cleanup classes. | Stale claims and missing workers trigger an actionable alert. |
| Add alerts that join queue evidence to a safe business fixture. | Capture pending, claimed, completed, failed, canceled, retry, and long-running fixtures with stable IDs. | Retries and deployment drains preserve idempotent business outcomes. |
| Document claim recovery, retry, idempotency, and deployment drain procedures. | Alert on oldest age, percentile age, claim duration, retry slope, failure rate, worker heartbeat, and business outcome lag. | Queue metrics return to baseline after the controlled recovery test. |
Why this usually happens
- Total depth hides one old action behind many fresh completions.
- Different hooks have very different expected runtimes and customer impact.
- A deployment can leave claims owned by workers that no longer exist.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
hook,group,oldest_s,slo_s,p95_s,claims,retries,worker_version,business_state,burn
payment_webhook,orders,420,300,260,1,1,11.0.1,pending,1.40
email,customer,190,600,150,2,0,11.0.1,queued,0.32
log_cleanup,maintenance,4800,21600,4100,1,0,11.0.1,none,0.22
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Payment webhook | Five-minute age objective | Alert before order remains pending |
| Cleanup task | Six-hour age objective | No false urgent page |
| Stale claim | Worker disappeared | Recover through documented claim path |
| Deployment drain | Old and new worker cohorts | One completion on approved package |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Classify hooks by user impact and expected duration.
- Set age, completion, retry, and claim objectives with named owners.
- Add alerts that join queue evidence to a safe business fixture.
- Document claim recovery, retry, idempotency, and deployment drain procedures.
- Run a controlled failure and prove the queue plus business state recover.
Decision rule
Call the queue healthy only when every critical hook class stays within its age objective, claims have live owners, retries remain bounded, and the joined business result completes exactly once.
Production verification checklist
- Critical oldest-action age and burn rate are visible by hook class.
- Stale claims and missing workers trigger an actionable alert.
- Retries and deployment drains preserve idempotent business outcomes.
- Queue metrics return to baseline after the controlled recovery test.
Field notes
- Use synthetic order and customer data in reusable alerts.
- Page on customer-impacting age, not every delayed maintenance action.
- Keep the original error and claim evidence before retrying manually.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and a narrow synthetic fixture. Perform destructive, version, cache-policy, queue, or schema changes on staging first, then promote the smallest proven change.
What evidence should be kept?
Keep versions, fixture IDs, UTC timestamps, request or export evidence, expected and actual results, the decision owner, rollback point, and the final clean verification. Redact personal data.
When is the work finished?
Finish when the canonical user path passes, downstream records reconcile, failure cases are understood, monitoring is in place, and an established page links to the new guide with useful context.
Mistakes to avoid
- Changing production before preserving a reproducible fixture, timestamps, and the current result.
- Treating one successful screen, request, or export as proof that every downstream system agrees.
- Removing logs, identifiers, or rollback evidence before the owner and failure boundary are known.
- Testing only an administrator session instead of the roles, devices, consent states, and failure paths users actually have.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, 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, stabilize a WooCommerce queue.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references