WooCommerce Auto-Renewal Not Working: Diagnostic Guide

What to check when WooCommerce auto-renewal is not working

When a WooCommerce subscription does not renew automatically, check the evidence in this order: the subscription's intended billing mode and next payment date, Action Scheduler, the renewal order and its notes, the saved payment method, the payment gateway's transaction record, and any active retry. Do not trigger another charge until you know whether the gateway already took payment.

“Auto-renewal not working” can describe several different states:

• no renewal action was scheduled;
• an action is pending, late, failed, or timed out;
• a renewal order exists but payment failed;
• the gateway captured payment but WooCommerce did not reach the matching local state;
• the subscription is intentionally set to manual renewal;
• a retry is waiting;
• two processes created duplicate renewal activity.

The fix depends on which state exists. Start with a timeline and keep diagnosis separate from remediation.

WooCommerce's official documentation says WooCommerce Subscriptions uses Action Scheduler for scheduled subscription events. Its common renewal issues guide covers missing renewal orders, failed renewals, duplicate orders, and payment-token problems. Its scheduled action errors guide explains how order notes and gateway records help locate where a renewal stalled.

First, confirm that automatic renewal is expected

Open the affected subscription and record:

• subscription ID and status;
• billing mode: automatic or manual;
• payment gateway;
• next payment date;
• last payment date;
• latest related renewal order;
• saved customer and payment-token references, without copying secret values;
• customer renewal preference if the installed version exposes it;
• any pending payment retry.

A manual subscription is not a broken automatic subscription. WooCommerce documents both manual and automatic payment methods in its Subscriptions payment gateway guide. Gateway support, token availability, customer choice, imported data, and store configuration can all affect the billing mode.

Also confirm that the next payment was actually due. Timezone, synchronized renewal dates, trial periods, early renewals, manual date edits, and migrations can change the expected timeline.

Build a renewal timeline

Write down events from both systems rather than reading only the current status.

For WooCommerce, collect:

• scheduled-action creation and due time;
• action status and execution time;
• renewal-order creation time;
• order status changes;
• order notes;
• subscription status changes;
• retry events;
• administrator actions.

For the gateway, collect:

• transaction time;
• amount and currency;
• customer and payment-method reference;
• order, renewal, or subscription reference;
• authorization, capture, failure, void, or refund status;
• gateway event or webhook identifier.

Normalize timestamps to one clearly named timezone for comparison, but preserve the original values. A five-minute difference may be normal processing latency; a one-day difference may indicate the records do not belong to the same billing attempt.

Diagnostic sequence

1. Check Action Scheduler

Go to WooCommerce Status and inspect Scheduled Actions for the affected subscription. Look for the relevant scheduled subscription payment action and record whether it is complete, pending, failed, canceled, or past due.

If many actions are overdue, investigate WP-Cron or Action Scheduler as a system issue. WooCommerce's complete guide to scheduled events with Subscriptions describes how comparing cron and scheduler dates can help isolate where processing stopped.

Do not assume that a failed or timed-out action means no money moved. A process can fail after the gateway captured payment but before WooCommerce updated the order and subscription.

2. Find the renewal order

Open Related Orders and determine whether a renewal order exists for the billing period.

• No order may indicate the process stopped before order creation.
• A pending or failed order may indicate a payment issue or incomplete processing.
• A processing or completed order may indicate that billing succeeded locally.
• More than one order for the same period may indicate duplicate action or manual intervention.

Use the order notes to reconstruct the sequence. Do not change status merely to make the dashboard look correct.

3. Check the saved payment method

Confirm that the subscription points to a valid payment method for a gateway that supports the intended automatic renewal behavior. A missing, detached, expired, or migrated token can prevent payment.

Never expose a complete token or gateway credential in a diagnostic export. Stable non-secret references and the gateway's own masked display are normally enough for matching.

4. Check the gateway independently

Search the gateway by the order or renewal reference, subscription reference, customer, amount, currency, and time. This is the critical step before a retry.

Possible outcomes:

• No transaction found: payment may not have reached the gateway.
• Failed or declined: local failure may accurately reflect the provider outcome.
• Authorized or captured: do not charge again; investigate local state and webhook processing.
• Multiple matching transactions: treat as a possible duplicate and escalate through the approved payment process.
• Ambiguous match: obtain more evidence before acting.

5. Review retries and webhooks

Check whether WooCommerce has scheduled a failed-payment retry. Check gateway webhook or event-delivery evidence where the integration exposes it. A retry waiting for a future time is different from a permanently stuck renewal.

Avoid manually processing a renewal while an automated retry or delayed gateway event can still run unless the operator has deliberately controlled that race.

6. Use native health checks

Current WooCommerce documentation describes a Subscriptions Health Check for signals such as potentially incorrect manual billing mode and missing or overdue renewal dates. Use it as a native diagnostic source. Review every proposed action before confirmation; a reconciliation audit should complement, not pretend to replace, native controls.

Worked synthetic reconciliation

Assume a store exports two expected renewals.

Renewal R-100

• subscription: S-9;
• expected amount: USD 49.00;
• due: 20 July 2026;
• WooCommerce state: failed;
• gateway transaction: USD 49.00 succeeded on 20 July;
• gateway external reference: R-100.

This is a state-divergent candidate. The store says failed while the gateway has a matching success. The safe next step is not another renewal attempt. Review order notes, the gateway event, webhook delivery, and the authorized process for aligning the local record.

Renewal R-101

• subscription: S-10;
• expected amount: USD 29.00;
• due: 21 July 2026;
• WooCommerce state: pending;
• matching gateway transaction: none in the supplied export.

This is a missing-provider-transaction candidate, not proof that payment must be retried. Check whether the action is pending, whether a retry exists, whether the export is complete, and whether the gateway uses a different reference.

The two records appear similar in an “unpaid renewals” report, but they require opposite risk controls. R-100 carries duplicate-charge risk if retried. R-101 may need scheduler, token, or gateway investigation.

Auto-renewal diagnostic checklist

Preserve evidence

• Export the affected subscription and related-order identifiers.
• Record the observation time and timezone.
• Save relevant order notes and scheduler statuses.
• Obtain the bounded gateway transaction evidence.
• Redact credentials and unnecessary customer data.

Verify expected state

• Is the subscription active or otherwise eligible to renew?
• Is billing mode automatic?
• Did the customer intentionally opt for manual renewal, if that feature is in use?
• Does the gateway support automatic subscription payments?
• Is a valid saved payment method attached?
• Is the next payment date correct?

Verify execution

• Was the scheduled payment action created?
• Did it run?
• Did it fail or time out?
• Was a renewal order created?
• What do its notes show?
• Is a retry already pending?
• Did an administrator manually create or process an order?

Reconcile money

• Is there a gateway transaction for the same reference?
• Do subscription, amount, currency, and time align?
• Was the transaction failed, authorized, captured, voided, or refunded?
• Are there multiple candidate transactions?
• Is the gateway export complete for the time window?

Approve remediation

• Assign a reviewer for financial-impacting changes.
• Control scheduler and retry races before manual action.
• Follow the official support path or gateway process for uncertain charges.
• Record the reason for any order or subscription change.
• Re-run the reconciliation afterward.

Common mistakes

Retrying before checking the gateway

The local failure may have occurred after capture. A blind retry can create another charge.

Treating every overdue date as a gateway failure

The issue may be billing mode, scheduling, cron, an incomplete migration, or a missing renewal order before the provider was called.

Matching on amount alone

Many customers pay the same amount. Use the strongest available combination of renewal reference, subscription, gateway event, amount, currency, and time.

Changing production data to test a theory

Status edits and manual renewals can trigger side effects. Reproduce with a safe test setup where possible and use approved production procedures when customer money is involved.

Assuming the newest status tells the whole story

Current state hides sequence. The order notes, scheduler, retries, and gateway events provide the timeline.

What reconciliation can and cannot do

A read-only reconciliation can identify missing, orphaned, duplicate, mismatched, and state-divergent candidates. It can preserve why a record was flagged and estimate the face value associated with exceptions.

It cannot prove recoverable revenue, customer intent, charge validity, settlement, tax treatment, refund eligibility, or the correct remediation. Gateway-specific behavior, disputes, fees, partial refunds, and asynchronous events require separate review.

To compare synthetic WooCommerce renewals with provider transactions, run the RebillLens sample and use the same page to request a paid forensic renewal audit. The audit is read-only and does not retry, capture, refund, or edit subscriptions.