Job woo-subscription-renewals-not-processing · revised 11 October 2026
Fix WooCommerce Subscriptions renewals that are late or never created
On a store copy, a test subscription due now gets its renewal order created inside an agreed window and its next renewal scheduled, with the scheduling cause named and documented.
You might be seeing
- Renewal orders appear hours or days after the due date
- Renewals appear in a burst when you log in to the admin
- Subscriptions show a past renewal date and no new order
- Subscriptions drop to manual renewal after a plugin change
No passwords, keys, card details or admin invites needed to start.
What usually happened
WooCommerce Subscriptions creates each renewal order from a scheduled task run by Action Scheduler. That queue is started by WordPress's page-load scheduler and by admin visits, so a site where the scheduler never fires, fires rarely, cannot call itself, runs out of time, or has its payment plugin switched off leaves renewals due but not created, with no error shown to the subscriber.
Who it’s for: Owner of a WooCommerce store selling subscriptions whose renewals are created late, in bursts, or not at all.
Usually starts when: Subscribers complain they were not charged or invoiced on the due date, or renewal orders only appear when someone opens the admin.
The result: On a copy of your store, a test subscription made due now has its renewal order created inside an agreed window and its next renewal scheduled, and the scheduler setting or server change that makes this reliable is written down.
Check whether this job fits
Five questions, about two minutes. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
Look at the scheduled tasks list
In your WordPress admin, open the list of scheduled actions and filter to subscription payment tasks.
Look for: Pending tasks whose due time is hours or days in the past, or failed tasks with a timeout note.
Compare renewals with admin visits
Note the time of the last renewal order and whether anyone opened the admin around then.
Look for: Renewals that appear only when someone logs in, which points to an unreliable scheduler trigger.
What you get
- A note naming why renewals were late or missing, with redacted scheduler evidence
- The store-side corrections made on the copy and the server or host change needed
- A test table: test subscription, due time, when the order was created, next renewal date
- A list of overdue live subscriptions for you to review, produced from the evidence you send
- Steps to apply the changes to the live store and to undo them
Included
- The scheduled tasks behind renewals: pending, past-due, failed and stuck entries
- How the scheduler is started on your host: page-load trigger or a server job, and whether the site can call itself
- Whether subscriptions are on automatic or manual renewal and why any fell back to manual
- A test renewal on the copy, and the exact setting or server change needed on live
Not included
- Charging or renewing live subscribers, which you do under your own account
- Failed-payment retry rules, dunning emails and card decline causes
- Changing prices, plans or subscription terms
- Switching to a different subscription plugin
- Refunds and customer communication about missed renewals
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
A test subscription made due now gets its renewal order created inside the agreed window on staging
Evidence: Order number, creation time and the due time
After the renewal, the next renewal date is scheduled and the test subscription is in the expected status
Evidence: Screenshot of the subscription page
No scheduled subscription payment task on staging is pending past its due time by more than the agreed margin
Evidence: The scheduled task list filtered to subscription tasks
The written scheduler setting matches what the host confirms is running
Evidence: The host confirmation and the setting we specified
Sign-off. You review the test table and the evidence and sign off before payment. Changing the live scheduler and reviewing overdue subscribers are separate steps you take.
If it fails. If the checks do not pass, you do not pay, and we hand over what we found so anyone can continue.
When it fits, and when we stop
It fits when
- The store uses the official WooCommerce Subscriptions extension with an active licence
- A staging copy exists, or your host can make one, with live payments switched off
- The payment gateway supports changing a test subscription's renewal date, or a manual-payment test route is acceptable for the scheduling check
- You, or your host, can change the scheduler or server job we specify
We stop and tell you if
- Renewal orders are created on time and the fault is a declined payment
- The host will not allow a server job or the site cannot reach itself over the network and the host cannot change that
- A different subscription plugin is installed
- There are signs of a compromise on the store
What could go wrong
Store-side changes are listed with their previous values and any server job is described with how to remove it. We never renew or charge live subscribers and do not change the live store.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A staging copy renews and charges real subscribers | Staging runs with live payments off, a test-mode gateway or a manual route, and we confirm that before any test. |
| A burst of overdue renewals fires at once when the scheduler is fixed on live | The handover lists overdue subscriptions and recommends how you reduce the backlog before applying the fix. |
| A server job runs too often and strains the host | We specify an interval, record what the host chose, and keep long-running tasks within the host limits. |
A second reviewer checks that staging could not charge a live subscriber, that the scheduler evidence supports the stated cause and that your host can apply and reverse the change.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Confirm the staging copy matches live versions, with live payments off and customer email off
- Read the scheduled task list and the notes on affected subscriptions
- Find the cause: scheduler never fires, fires rarely, cannot call itself, times out, or gateway off
- Apply the store-side correction on staging and specify the server change
- Make a test subscription due now and record when the renewal order appears and when the next one is scheduled
- Independent review, then hand over the evidence and steps; you or your host apply them live
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Platform, app and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
Discuss a recurring renewal-scheduling check after plugin updates as a separate agreement.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Ask your host whether WordPress scheduled tasks run from a server job. Many hosts can set one up, and it is often the whole fix on a quiet site.
- The WooCommerce Subscriptions documentation describes renewals and the failed-payment retry options; read it first if the order is created but payment fails.
Questions
Will you renew my live subscribers?
No. We never charge or renew a live subscriber. You review the overdue list we give you and act on it under your own account.
Do I need a server job?
Not always. A low-traffic site often does, because the default trigger depends on visitors. The evidence decides.
What if the payment fails after the order is created?
Then this job does not apply. That is a payment problem for the gateway log and your failed-payment settings.
Send an enquiry
Send us
- How many renewals were late, by how long and since when
- Whether late renewals appear when someone opens the admin
- Whether any plugin, host or WordPress setting changed before it began
- Whether your host runs a server job for WordPress scheduled tasks
- WooCommerce, Subscriptions and gateway versions, if you know them
Later, once you agree
- A staging copy shared the way you choose, with live payments off and a staging admin login
- Redacted screenshots or an export of the scheduled tasks list, with no customer details
- Your host's confirmation of how scheduled tasks are triggered on the server
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You keep the live store, hosting account and payment account. We work on a staging copy with live payments off, and you or your host make any scheduler or server change on live.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “woo-subscription-renewals-not-processing” as the subject.