Commerce save · Pattern story

Failed renewals quietly killed MRR. The agent saw it on day two.

A WC Subscriptions business doing low six-figure MRR. A patch to the payment gateway shipped during a routine update. No errors hit the logs. Nothing pinged. Renewals just started failing at a higher rate, slowly. The MRR drop accumulated for three weeks before anyone noticed in the books.

The setup

A subscription-first WooCommerce store. Most of the revenue is renewal, not new acquisition. The dunning sequence is finely tuned. The team watches new-signups and net-MRR weekly. Daily renewal volume is one of those numbers that's always "fine" until it isn't.

What broke

A gateway plugin patch broke renewals for customers whose stored payment details predated a 2023 change. Quietly. No error, no log entry, just a slightly higher failure rate on the renewals running through the affected cohort. The order was created, the payment attempt was made, the gateway returned a soft decline, the dunning sequence began.

Nothing about this was unusual. Failed renewals happen every day. Dunning runs every day. The rate just shifted a few percentage points, and the daily volume was small enough that no one noticed.

What the agent did

The agent learns each store's normal renewal volume. Day of week, end of month, seasonal shape, dunning lag. It alerts on the gap between expected and actual, not the raw count. The same drop that's invisible to a dashboard is loud to a model that knew what the day was supposed to look like.

Here's the kind of signal the agent surfaced (illustrative):

expected vs actual successful renewals, day over day: Mon ████████████████████ expected: 220 actual: 218 ok Tue ████████████████████ expected: 196 actual: 192 ok Wed ████████████████████ expected: 240 actual: 209 −13% unusual Thu ████████████████████ expected: 211 actual: 184 −13% unusual Fri ████████████████████ expected: 198 actual: 173 −13% alert

On the second day of the residual sitting at –13%, the agent escalated. Single message to Slack: "Renewal success rate down 13% vs expected for two consecutive days. Detail at /app/sites/<store>/subscriptions."

The dashboard linked to the suspect change: the gateway plugin update from earlier in the week. The team rolled it back, the renewal rate returned to expected on the next cycle, and the dunning queue (which had accumulated affected customers) was retried successfully against the restored gateway.

What would have happened without the agent

The MRR shortfall would have shown up in the next month's books. By then a meaningful percentage of affected customers would have moved through the dunning sequence to cancellation. The recoverable revenue becomes unrecoverable churn. The investigation post-fact takes a week, not a day, because the failure window is wide and the cause is buried in a routine update from three weeks ago.

Why this is the agent's job, not the dashboard's

A dashboard shows the renewal count. It doesn't know what the count should be. The agent does. That's the difference.