Why WooCommerce Subscriptions renewals run late: the scheduler behind every renewal

A renewal is a scheduled task, not a charge waiting to happen

WooCommerce Subscriptions does not watch the clock itself; each renewal is a scheduled event. When a renewal falls due, the plugin's documentation describes a scheduled subscription payment being triggered, the woocommerce_scheduled_subscription_payment event in Action Scheduler, and a renewal order being created. With automatic renewals the original payment gateway is then charged. With manual renewals the order starts as Pending payment, and the customer is emailed a Customer Renewal Invoice to pay if your store has that email enabled.

That means a late renewal can be two different faults. Either the task did not run on time, which is a scheduling problem, or it ran and the payment failed, which is a gateway problem. They need different evidence, and this guide covers the first. A renewal order that exists but whose card payment failed is not a scheduling fault; by default, a failed payment leaves the subscription on hold, and the customer is emailed about it only if the Customer Renewal Invoice email is activated.

• No renewal order at the due time: look at scheduling.
• Renewal order created, payment failed: look at the gateway log and failed-payment settings.
• The next renewal date counts from the last actual payment, so a late payment shifts later dates.

What starts Action Scheduler

Action Scheduler is a queue library that WooCommerce and many extensions use for background work. Its documentation describes two triggers. The first is WP-Cron, which fires the runner about once a minute. The second is the admin: on admin requests it checks for pending actions at the end of the request and, if any are due, starts a queue through an asynchronous loopback request, meaning the site calls itself over the network.

Once started, a runner claims 25 actions at a time and keeps going until it reaches 90 percent of available memory or 30 seconds, then asks for a new loopback request if work remains. Claims older than five minutes are released, and an action running longer than five minutes is marked failed. A large backlog, a slow host or a loopback request that the host blocks can therefore leave tasks waiting or failed with no message to a subscriber.

Why quiet sites and disabled cron leave renewals overdue

WP-Cron is not a clock. WordPress documents that it runs only when someone loads a page, checks its queue and runs whatever is due. A job set for 2pm on a site nobody visits until 5pm runs at 5pm. Overdue jobs are not skipped; they run on the next request. For a subscription store that means renewals bunch up behind visitors, and a quiet night can push them hours late.

Many hosts replace the page-load trigger with a real scheduled job. The WordPress handbook describes setting DISABLE_WP_CRON in the site configuration and making the host call the cron file on a schedule instead, for example every fifteen minutes. If the first half was done and the second half never was, nothing triggers the scheduler except admin visits, which matches the symptom of renewals that appear only when someone logs in.

• Ask the host: is WordPress cron the default, or is there a server job calling it?
• If the constant is set, confirm a server job exists and runs.
• Check whether the site can request its own address; a firewall or password gate can block the loopback.

A safe first investigation on a copy

Use a staging copy with live payments off, never the live subscriptions. Look at the list of scheduled tasks and filter to the subscription payment tasks.

Check how your copy behaves before you test. WooCommerce Subscriptions records the address of the site where it was first activated, and if the copy has a different address it runs in staging mode: automatic payments and subscription emails are switched off and every subscription is treated as a manual renewal, but scheduled renewals still fire and create renewal orders. That is what you want for this test. A copy that keeps the live address, for example after a database migration on the same domain, does not trigger staging mode, so Subscriptions may treat it as the live site and could still try to charge subscribers; do not test on such a copy unless live payments are off at the gateway.

• Pending tasks whose due time is hours or days in the past point at a trigger that is not running.
• Failed tasks with a timeout note point at memory, time or loopback limits.
• Check whether subscriptions fell back to manual renewal because a gateway plugin was deactivated; reactivating it should restore automatic renewals.
• Make a test subscription due now: Subscriptions can trigger a renewal for a test subscription only with a manual-payment gateway or a gateway that supports changing the renewal date.
• Record when the renewal order appears and when the next renewal is scheduled.

What fixes it, and what does not fit

Fixes are in two places. On the store, make sure the gateway plugin is active, clear tasks that failed for a documented reason, and settle the configuration. On the server, make sure something triggers WordPress cron regularly, at an interval your host accepts. If an overdue backlog exists, reduce it deliberately before the scheduler is fixed on live, so hundreds of renewals do not fire at once. Declined cards, retry rules, price changes and refunds are outside a scheduling repair, and no staging test should ever renew or charge a live subscriber.

How the paid fix is accepted

The fixed job for this problem is accepted on a staging copy with live payments off. A test subscription made due now gets its renewal order created inside the agreed window, its next renewal is scheduled, no subscription payment task is pending past its due time by more than the agreed margin, and the scheduler setting we specify matches what your host confirms is running. We never renew or charge your live subscribers; you review the overdue list we produce and act on it under your own account.