Subscriptions not renewing
Nobody cancelled. The renewals just stopped happening.
Failed subscription renewals are the quietest revenue leak in e-commerce: no error on the site, no complaint from customers — who rarely notice they stopped being charged — just a recurring-revenue line that sags for reasons nobody can name. The machinery has three moving parts, and each fails differently.
Same-day diagnosis. Flat quote before any fix.
What’s actually happening
A renewal is three systems agreeing: the scheduler (WordPress cron / Action Scheduler) must fire on time to create the renewal order; the stored payment token — the card-on-file reference living at your gateway — must still be valid and still be attached to the right customer; and the gateway must accept the off-session charge. Silence from any of the three means no renewal, and because the failure produces no customer-facing error, the store's owner is the last to know.
Two causes dominate. Scheduler starvation: WordPress cron runs piggybacked on site traffic, and on low-traffic sites or under aggressive caching, scheduled renewals queue up unfired — the Action Scheduler's pending list grows while revenue doesn't. And token loss after change: migrations, gateway account changes, or switching payment plugins can orphan the stored tokens — subscriptions still exist, but their connection to a chargeable card is gone, converting automatic renewals into 'manual renewal required' emails customers ignore. The repair is diagnosis across all three systems, then reviving what's revivable — and the honest accounting of which lapsed subscriptions can be win-back campaigns versus which renew on the next cycle.
The usual causes, ranked
After twenty-seven years of these calls, the odds are well mapped. Start at the top.
Cron and Action Scheduler starvation
Renewal actions queued but never run — low traffic, caching layers, or a broken cron trigger. The pending-actions pile is the tell.
Payment tokens orphaned by change
Migrations, gateway switches, or plugin changes disconnecting subscriptions from their stored cards — automatic quietly becomes manual.
Gateway declines with no retry follow-through
Expired cards and soft declines where the dunning/retry emails aren't sending — one decline becoming permanent churn.
Staging copies talking to live gateways
A staging site processing (or being detected and blocked from processing) renewals — the classic duplicate-site subscription mess.
What you can safely try first
Nothing below can make things worse — that’s the selection criterion. Anything riskier belongs in professional hands, on a backup.
- 1
Read the Action Scheduler queue
WooCommerce → Status → Scheduled Actions: filter for pending subscription actions past their date. A backlog is the scheduler diagnosis, on screen.
- 2
Audit one failed subscription end-to-end
Pick a subscription that should have renewed: does it show a stored payment method? Does the gateway dashboard show a matching customer and token? The single-case audit usually names the layer.
- 3
Count the damage honestly
Filter subscriptions by status — on-hold, pending, manual-renewal. The size and pattern (all since a date? one gateway?) points at the event that caused it.
Stop and call when…
- Tokens are orphaned — re-linking gateway customers to subscriptions is precise, per-record work with real money attached
- Renewals must be caught up without double-charging anyone — sequencing matters enormously
- The cron fix needs server-level scheduling (real cron replacing traffic-dependent cron) — configuration, done once, done right
From there it’s our job: same-day look, flat quote, and the $389 flat repair covers most cases of exactly this.
Form & Email Rescue — buy it now, skip the hunt.
Contact forms delivering again, order and notification emails reaching inboxes.
Covers form and site-email failure on one site: broken submissions, vanishing notifications, spam-folder exile. Includes deliverability setup (SPF/DKIM) where the fix needs it.
Questions we hear a lot.
Can lapsed renewals be recovered, or is that revenue gone?
Split answer. Subscriptions with valid tokens that simply never fired: recoverable — renewals can run late, carefully, without doubling anyone. Orphaned-token subscriptions need the customer's card again — that's a win-back email flow, and the sooner it goes out the higher the recovery rate. Part of the fix is sorting your list into those two piles and acting on both.
Why didn't customers tell me they weren't being charged?
Because from their side nothing happened — no failed-payment email (those weren't sending either), no service interruption if you didn't cut access, just a charge that quietly stopped. A few honest souls write in; most don't notice, and some notice and stay quiet. Silent churn is silent on both ends — that's exactly what makes it dangerous.
What does the $389 fix include?
All three systems: the scheduler repaired onto reliable server-side cron, tokens audited and re-linked where the gateway allows, retry/dunning emails verified actually sending, the backlog processed without double-charges, and the unrecoverable segment handed to you as a clean win-back list. Priced with the money-path rescues because recurring revenue is the money path.
Related symptoms & help
Errors travel in packs. If this one visited, check its friends.
Recurring revenue, actually recurring. Verified.
Send the symptom, get a same-day look and a flat quote from the developer who's fixed this exact thing more times than either of us can count.