How Long Should a Dunning Sequence Be? The Day-by-Day Cadence That Actually Recovers Revenue

The 30-second answer

For a typical monthly SaaS plan, a dunning sequence should run about 10-14 days from first failed payment to access pause: 3-4 emails, a couple of smart retries spaced across at least one payday cycle, and a grace period that doesn't drag into next month's renewal. Shorter throws away recoverable revenue. Longer trains customers to ignore you and pollutes your metrics with zombies.

That's the headline. The rest of this post is the reasoning, because the right answer genuinely depends on your decline mix, your price point, and how your customers get paid. Let's build it up properly.

Why sequence length is a trade-off, not a setting

Every day your dunning sequence runs, two forces fight. Working in your favor: balance cycles. A huge share of soft declines are timing problems — the account was empty at 3 AM on a Tuesday, not empty forever. Given days, money lands and retries succeed. Working against you: attention decay. Every email after the first gets opened less, and every day of 'we'll get to it eventually' teaches the customer that your payment requests are optional.

The art is giving the first force enough time to work without letting the second one rot the relationship. Ten to fourteen days hits that window for most consumer and SMB subscriptions: long enough to catch a payday, short enough to still feel like a live conversation.

The day-by-day cadence I'd run

• •Day 0 — payment fails. Immediate email: 'Your payment didn't go through.' Light tone, one link to fix it. No threats. Also queue retry 1 for 2-4 days out, aimed at a payday boundary if it's an insufficient funds decline.
• •Day 3-4 — retry 1 fires. If it succeeds, sequence ends silently (most recoveries end here and the customer never thinks about it again). If it fails, email 2 goes out: still friendly, now with the first mention of a deadline.
• •Day 7-8 — retry 2 fires at the next balance peak. If it fails, email 3: direct and clear. 'Your access pauses on [date] unless this is sorted. Takes one minute: [link].' Still human, but the stakes are now explicit.
• •Day 10-14 — final notice. 'Access pauses tomorrow.' Then actually pause it. A deadline you don't enforce is worse than no deadline — it's proof your emails are noise.
• •Day 14-30 — the tail. Access paused but account not cancelled. Some customers resurface here with a working card. Keep the door open with a self-serve reactivation link, but stop emailing. They've made their choice for now.

Adjust the length by decline type

That cadence assumes soft declines — insufficient funds, generic bank weirdness, the recoverable stuff. Hard declines change the math completely. A stolen_card or closed account will never succeed on retry, no matter how many paydays you wait for. Running the full 14-day retry cadence on a dead card is just delay for no reason. For hard declines: skip the retry spacing, send the 'we need new card details' email immediately, and shorten the runway to about a week. Different failure, different clock.

Adjust for price point and plan type

• •Cheap monthly plans ($10-50/mo): the 10-14 day standard. These customers churn and return casually; a long chase isn't worth it.
• •Higher MRR plans ($100+/mo): stretch the grace, add a personal touch. A founder-signed email on day 7 ('anything I can help with?') recovers accounts that templates don't.
• •Annual plans: completely different animal — bigger amount, staler card, higher stakes. That deserves its own playbook, and I've written one separately.
• •B2B annual contracts: here the 30-day enterprise cadences make sense — invoices get routed through accounting departments, and the 'customer' paying isn't the 'customer' using. Match the sequence to how businesses actually pay bills.

How to tell your sequence is the wrong length

You don't have to guess. Your own data tells you. Pull your last quarter of failed payments and look at the recovery curve: what share of recovered payments came back on day 1, day 3, day 7, day 14? For most subscription businesses the curve is front-loaded — a big chunk recovers in the first few days, a meaningful tail through about day 14, and a long flat nothing after. Your sequence should end where the curve flattens, not before it and not long after. If you don't have enough failures to see a curve yet, use the 10-14 day default and revisit in a quarter.

The other diagnostic is behavioral. If customers routinely fix their payment AFTER your access got paused, your sequence was too short — they needed two more days and you cut them off. If customers routinely ignore every email until the final notice, your sequence might be too long — they've learned the early emails don't matter. Both are fixable by moving the window, not by adding more emails. Watch the trend monthly; the right length drifts as your customer mix changes.

What about Stripe's default retry schedule?

Stripe Billing's built-in dunning lets you pick a retry schedule, and the defaults lean short — which fits their job: recover the easy soft declines fast, then hand off. The mistake is treating Stripe's retry schedule as your entire dunning sequence. Retries without emails recover only the customers who didn't need telling. The sequence in this post wraps around whatever retry schedule you choose: retries handle the money timing, emails handle the humans, and the total window stays in that 10-14 day zone for monthly plans. It also means you can be aggressive about turning Stripe's retry count down once your email layer is strong — fewer, smarter retries beat a wall of silent attempts.

And if your failed volume is high enough that you're tuning any of this, you're past the point where manual works. A handful of failures a month you can run from a spreadsheet and your own inbox. Dozens a month need a system.

Mistakes that wreck sequences

• •Seven emails in fourteen days. More emails after the third don't recover more revenue — they recover less, because now you're spam and everything you send gets filtered mentally or literally.
• •The unenforced deadline. 'Final notice' followed by three more final notices teaches customers your word means nothing. Say it once, mean it, do it.
• •Retrying daily for two weeks. Beyond burning goodwill with the card networks, frequent failed retries can get flagged as unusual activity. Two to three well-timed retries beat fourteen desperate ones.
• •Cancelling on day 3. The mirror-image mistake: one failed payment, one email, cancelled. You just threw away everyone who would have fixed it on payday. That's the most expensive impatience in SaaS.

"A dunning sequence is a negotiation with time. Give timing enough room to fix soft declines, and give deadlines enough teeth to matter. Most founders get exactly one of those right."

If you're building this by hand, the cadence above is genuinely all you need to start — day 0 email, two payday-aware retries, escalating clarity, enforced deadline. If you'd rather not babysit it: this is literally what StayPaid runs out of the box, with the timing tuned per decline code and the emails going from your own address so they read like a person, not a billing robot. Either way, the sequence length question has a real answer now: 10-14 days, 3-4 emails, then mean it.