Skip to main content
VaultDevLabs
Evidence guide

WooCommerce Action Scheduler failed actions and stuck orders

Check failed actions, WP-Cron and logs when WooCommerce payments, orders, emails or subscriptions stop updating.

Evidence before edits
No automatic changes
Clear next action
Decision map

01 · Observed signal

Stripe shows a succeeded payment while the matching WooCommerce order remains pending.

02 · Evidence to inspect

The Stripe PaymentIntent or Checkout Session status, amount, currency and event timestamp.

03 · Safe next move

Match the payment, order and scheduled-action timestamps before changing the order.

Start here

Understand the problem before changing the system.

Failed or overdue Action Scheduler jobs can leave WooCommerce orders, payment webhooks, emails and subscriptions waiting in the background. A failed action does not prove revenue loss, but its timestamp can explain why a paid order or renewal did not move forward.

Signals

What the issue can look like.

  • 01Stripe shows a succeeded payment while the matching WooCommerce order remains pending.
  • 02Action Scheduler shows repeated failed or overdue actions around the payment timestamp.
  • 03Order notes stop before the expected paid or processing transition.
  • 04Customer emails, stock changes or subscription updates are delayed after payment.

Possible causes

What may have interrupted the expected path.

  • WP-Cron is unreliable or disabled without a server cron replacement.
  • Plugin updates introduce failing scheduled actions or incompatible callbacks.
  • Hosting limits, timeouts, or fatal errors interrupt background processing.
  • Large queues hide failed or stuck actions until a customer-facing issue appears.

Evidence checks

What to verify first.

  • Review failed, pending, and overdue Action Scheduler actions if admin access is available.
  • Check whether WooCommerce, payment gateway, or subscription actions are failing repeatedly.
  • Compare failed action timestamps against order/payment incidents.
  • Fix the underlying callback, cron, hosting, or plugin conflict before clearing queues blindly.

Evidence to collect

  • The Stripe PaymentIntent or Checkout Session status, amount, currency and event timestamp.
  • The matching WooCommerce order status, order notes and gateway transaction reference.
  • Failed, pending and overdue Action Scheduler rows from the same time window.
  • The action hook, group, attempt count and complete failure message.
  • WooCommerce fatal-error and gateway logs covering the first failed attempt.

What not to do

  • Do not bulk-delete failed actions before recording their hook, timestamp and error.
  • Do not mark an order paid solely because a scheduled action exists or a webhook returned HTTP 200.
  • Do not replay live payment events or retry state-changing actions without an authorised recovery plan.
  • Do not assume every failed background action caused the customer-facing order problem.

Synthetic incident trace

See where an acknowledged payment path can still stop.

This is a reproducible synthetic fixture, not a client case study or claimed production incident. Hook names and log formats vary by gateway and plugin. It demonstrates the evidence relationship only and performs no diagnosis or order changes.

Expected state

Stripe succeeded → scheduled state callback completed → WooCommerce processing

Observed state

Stripe succeeded → scheduled callback failed → WooCommerce pending

  1. 09:14:02

    01 · Payment succeeded

    Synthetic PaymentIntent pi_vdl_…7Q2 reports succeeded for GBP 129.00.

  2. 09:14:03

    02 · Webhook acknowledged

    The synthetic endpoint returns HTTP 200 after validating the fixture event.

  3. 09:14:04

    03 · State action queued

    Synthetic action as_vdl_1842 is queued to apply the matching order transition.

  4. 09:19:04

    04 · Scheduled callback failed

    The fixture callback stops before the WooCommerce state update completes.

  5. 09:20:00

    05 · Mismatch confirmed

    Payment evidence remains succeeded while synthetic order wc_vdl_4821 remains pending.

Synthetic log excerpt

[09:14:02] payment_intent.succeeded pi_vdl_…7Q2 amount=12900 currency=gbp
[09:14:03] webhook fixture_evt_01 response=200 signature=fixture_valid
[09:14:04] action as_vdl_1842 hook=vdl_fixture_apply_order_state status=pending
[09:19:04] action as_vdl_1842 status=failed error="Synthetic downstream callback stopped"
[09:20:00] order wc_vdl_4821 status=pending expected=processing

Decision path

Move from signal to evidence to action.

Use the smallest safe step that resolves uncertainty. Implementation comes after the evidence is clear.

  1. 01Match the payment, order and scheduled-action timestamps before changing the order.
  2. 02Confirm whether the failed hook belongs to the payment-state path or an unrelated background task.
  3. 03Repair or isolate the failing callback, then rerun only the smallest authorised action needed.
  4. 04Verify the final WooCommerce state against Stripe evidence and record the before-and-after result.

Quick answer

What does this usually mean?

Failed or overdue Action Scheduler jobs can leave WooCommerce orders, payment webhooks, emails and subscriptions waiting in the background. A failed action does not prove revenue loss, but its timestamp can explain why a paid order or renewal did not move forward.

First check

What should be checked first?

Review failed, pending, and overdue Action Scheduler actions if admin access is available.

Need a human decision?

Check the evidence before changing a live system.

If failed actions line up with a paid-but-pending order, request a £99 Payment Rescue Review for founder-led evidence confirmation and clear next steps.