What happened
Every night at 02:00 the store charges thirty or forty subscription renewals in one batch. On a normal night one or two fail, usually because a card has expired, and the store’s retry rules and reminder emails deal with them.
On this night the payment provider was slow, not down. Charges that usually take a second took fifteen, and 14 of the 38 timed out before the provider answered. At 02:10 Operanse recorded a warning: 14 of 38 renewals failed, against one or two normally.
The failed renewals were rescheduled, and the store’s queue of scheduled tasks (Action Scheduler) backed up with about thirty overdue tasks. It worked through them by about 04:20.
Operanse did not send an alert in the night. At 02:30 it checked whether payments outside the batch were also failing, and they were not. The store could still take money; one batch had had a bad night. That is a warning for the morning summary, not a reason to wake someone up.
The night, replayed at eight minutes a second. The revenue figure at the top counts renewal income, so it shows a gap at 02:00 and recovers most of it at 05:00.
The renewals at 3 am. Fourteen of thirty-eight renewals failed in the two o’clock batch and the job queue backed up behind them. A warning in the morning digest, never an alert in the night; eleven went through on the first retry at 05:00.
- 02:10Renewals · Warning: 14 of 38 renewals failed in the two o’clock batch, usually 1 or 2 · added to the daily digest, no alert sent
- 02:15Job queue · Unusual: 30 actions past due, usually 1 or 2; 14 renewal payments are scheduled to retry
- 02:30Renewals · Still open: no failure outside the batch since 02:15, too few for an alert · no alert sent
- 04:20Job queue · Back to normal: the queue drained to 2 past due
- 05:00Renewals · Retries: 11 of 14 went through on the first retry; 3 are due again at 17:00
- 05:10Renewals · Resolved after 180 minutes: 35 of 38 collected, 3 on retry · in the 08:00 digest, no alert sent
What happened next
At 05:00 the first automatic retry ran, with the provider back to normal speed. Eleven of the fourteen payments went through. The other three failed again, this time because the cards had expired, and were scheduled to retry later in the day.
A failed payment attempt is not the same as a lost subscription. Fourteen attempts failed at 02:00, but by 05:10 only three renewals were still unpaid, and those three needed the customer to update their card, not another retry.
The 08:00 summary showed the finance lead exactly that: the batch had failed and mostly recovered on its own, three renewals were unresolved because of expired cards, and the task backlog had cleared. Finance matched the recovered payments against the provider’s settlement report, and nothing needed escalating.
If this is happening on your store
None of the checks below need a monitoring tool, only access to WordPress admin and your payment provider’s dashboard.
What to check first
- In WooCommerce → Subscriptions, filter by On hold. A subscription goes on hold when its renewal payment fails, so a sudden jump is the quickest sign of a bad batch.
- In WooCommerce → Orders, look at the failed renewal orders and read their order notes for the gateway’s response. Timeouts and one repeated error point to the provider or the store; expired cards and insufficient funds are the usual background.
- In WooCommerce → Status → Scheduled Actions, search for
woocommerce_scheduled_subscription_paymentand look at Pending and Failed. Renewal actions still pending long after they were due mean renewals are not being attempted at all. - In the gateway’s dashboard, compare the batch’s minutes with an ordinary night: slower responses, a higher decline rate, or no attempts at all.
Telling the likely causes apart
- Many renewals failed at once and new checkouts were fine. A slow or degraded provider during the batch, as in this example. Retries will recover most of them.
- Renewals failing and new checkouts failing too. The gateway itself is broken for the store; treat it as a payment failure after an update or settings change.
- No renewal orders created, and scheduled actions past due. The queue that runs renewals has stopped, usually because WP-Cron is not running. Check your WooCommerce system status report for past-due actions and WP-Cron.
- Renewals switched to manual after a site move or a staging copy. WooCommerce Subscriptions turns off automatic payments when it sees a changed site address, so a copied or migrated site does not charge customers twice. Confirm the live site is recognised as live.
- Failures spread out with card reasons, at the usual rate. Ordinary churn, which retries and reminder emails exist to handle.
Confirming it has recovered
- Scheduled Actions shows no past-due renewal payments, and the backlog has stopped growing.
- After the retries, the renewal orders from the batch are paid and their subscriptions are Active again. What is left on hold should be customer-side failures, such as expired cards.
- The reminder emails for those customers are going out, so they can update their card.
- The provider’s settlement report matches the recovered payments.
How to prevent it
- Ask your payment provider when it runs maintenance, and schedule the renewal batch outside that window.
- Consider a shorter first retry, so a slow night costs one hour of delay instead of three. Leave later retries and reminder emails as they are.
- Look for repeats. One bad night is noise; the same failure every month points to a timing or provider problem.
- Don’t alert on every renewal failure. An alert at 2 am for a batch that recovers by 5 am teaches people to ignore alerts.
Related tools and examples
- Check your WooCommerce system status report: past-due scheduled actions and WP-Cron switched off are the two lines that stop renewals without any error.
- How renewals and retries are counted: first attempts and retries kept apart, so one payment is never counted twice.
- Estimate what failed renewals cost: use “Renewals failed” with the days it went unnoticed and the share retries recover. It counts the renewal at risk and the later renewals lost if the subscription ends, which is usually the larger part.
How Operanse catches it
Renewals are counted on the first attempt, and retries are counted separately, so the same payment is never counted twice. That is how the chart can show 14 of 38 failed, then 11 of 14 recovered, instead of one blended failure rate.
The daily summary is sent at 08:00 in the store’s own timezone and lists every warning from the night that did not need an alert. If there is nothing to report, it is not sent.
Operanse compares each store’s activity with its own history and groups related anomalies into incidents. Playback, the replay above, is on Monitor and Insight; Insight adds server monitoring and an AI review of the likely cause, with its evidence. How Operanse monitors a WooCommerce store.