A dunning email sequence is the highest ROI automation most SaaS teams set up too late. A failed payment is not a lost customer. It is a recoverable event, if you catch it fast and handle the sequence right. This post covers the mechanics: retry timing, email cadence, tone for each step, and when to let go.
Why dunning deserves more attention than it gets.
Involuntary churn, the kind caused by failed payments rather than a deliberate cancellation, is often the easiest churn to address. The customer did not decide to leave. They may not even know their card failed. A well-timed dunning sequence bridges the gap between a billing event and a lost subscription without requiring any human intervention.
Most small SaaS teams set up dunning late, or rely entirely on their billing provider's built-in emails, which tend to be generic and unstyled. Neither approach is wrong, but both leave recovery on the table. The sequence you build yourself, with the right timing and the right tone at each step, recovers more than the default.
Involuntary churn is quiet and recoverable.
A user who actively cancels has made a decision. A user who churned because their card expired did not choose to leave. They may not even know it happened. The dunning sequence exists to bridge that gap: recover the payment before the account lapses, and you keep a customer who never intended to churn.
The recovery window is narrow.
Card declines are often temporary: insufficient funds at billing time, an expired card that was just renewed, a bank flag on an unusual charge. If you retry at the right time and email quickly, recovery rates are high. If you wait too long, the user logs in to a locked account and the relationship is already damaged.
No other email sequence has this ROI.
Recovering a failed payment costs nearly nothing. You already have the customer. You already have the relationship. The email sequence is a few automated touches that run off a single billing event. The return on a well-built dunning sequence is among the highest of any lifecycle automation a SaaS can build.
Payment retries and dunning emails work together.
Your billing provider, whether Stripe or another processor, handles the actual retries. Your dunning emails run in parallel with those retries. The goal is to have the email arrive before or just after each retry attempt, so the user sees the alert when the issue is still fresh and the retry is still pending.
Here is the retry and email window that works well for most SaaS teams. Adjust the exact timing based on your billing cycle and your average payment method type.
| Retry | Timing | Why |
|---|---|---|
| First retry | 24 to 48 hours after initial failure | Catches temporary failures: insufficient funds at billing time that cleared the next day, a bank hold that lifted overnight. |
| Second retry | Day 3 to 4 | Catches expired cards that were just renewed. Many users update their payment method after the first email, so the retry succeeds without them needing to do anything else. |
| Third retry | Day 7 | Last automated attempt before suspension. Some billing tools let you configure a smart retry that checks bank response codes and avoids retrying on hard declines. |
Exit the sequence the moment a payment succeeds. A user who fixed their card should never receive the access-warning email. This is where automation beats a manual process: the sequence stops on the success event, not on a schedule.
A five-step dunning email sequence, step by step.
Each step has a different job. The tone escalates as the window narrows, but never becomes adversarial. Exit on payment success at every step.
Immediate: the soft alert.
Send within an hour of the first failed charge. Do not lead with "your payment failed". Lead with "we had trouble processing your payment" and treat it as a transient issue. Include a direct link to update the payment method. Keep the tone calm and assume good faith. Most card failures at this stage are temporary.
Day three: the retry notice.
If the retry on day three also fails, send a second email. Now you are a bit more direct: let the user know you will try again in a few days, and that updating their payment method is the fastest path forward. Still friendly, still no urgency language. A lot of users fix it at this touch.
Day six: the access warning.
This is where you introduce consequence without panic. "Your account will be suspended in X days" is the message, with the exact date. Keep it factual. The goal is to make the risk real without making the user feel blamed. If your billing provider supports a self-serve payment update link, this is where it matters most.
Day nine to ten: final warning.
One more email, one to two days before the account locks. Short. Specific date. A single link to update payment. No long explanation at this point. Users who are going to fix it know what to do. Users who are not going to fix it will not read a long email. Make it easy for the ones who want to stay.
Suspension day: confirmation.
When the account suspends, send a confirmation with a clear path to reactivate. This email does two things: it closes the loop for users who did intend to cancel (clean exit), and it gives users who missed every prior email one last chance to come back. Keep the reactivation link prominent.
Getting the tone right at each step.
Tone is where most dunning sequences go wrong. The two failure modes are being too soft (users miss the urgency and the account lapses) and being too aggressive (users feel blamed and churn voluntarily instead of recovering).
The first two emails should assume a transient issue and give the user an easy out: a one-click payment update link, a clear statement that the retry is automatic, and no urgency language. The middle email introduces the consequence but keeps it factual. The final warning is short and direct, with just the date and the link.
The frame that works across all five steps: you are on the user's side, trying to keep their account active. You are not collecting a debt. For a deep guide on writing each individual email, see the post on failed payment email tone .
Dunning is also a churn signal. A user who fails multiple dunning touchpoints without updating their payment may have intended to leave. See reducing SaaS churn with email automation for how to distinguish passive churn from silent disengagement.
How to automate a dunning sequence in GetFluxly.
The trigger is a payment_failed event from your billing
system. Fire it from your Stripe webhook handler or wherever your
billing logic lives, and send it to GetFluxly via the HTTP Events
API. From there, the automation takes over.
The automation has a wait step between each email, a branch to check
whether a payment_succeeded event has fired (exit if
it has), and an exit on event rule that stops the sequence the moment
payment recovers. The sequence sends through your existing ESP: Resend,
Mailgun, AWS SES, or any custom SMTP relay. GetFluxly drives the timing
and the logic; your ESP handles delivery.
Send outcomes flow back into the customer profile. A bounce on the billing alert email surfaces in the record, which is useful context if you are also looking at this user in the context of broader account analytics.
See pricing if you want to compare tiers, or read the lifecycle email automation guide for how dunning fits into the broader retention picture.
Dunning email sequence, answered.
What is a dunning email sequence?
A dunning email sequence is the series of automated emails sent to a subscriber after a payment fails. The sequence runs in parallel with payment retries, alerting the user to the failed charge, prompting them to update their payment method, and warning them before their account is suspended. The goal is to recover the revenue and keep the customer without requiring manual intervention.
How many dunning emails should I send?
Four to five emails over a seven to ten day window is the standard range for SaaS. The first goes out within hours of the failure. Subsequent emails are spaced two to three days apart and escalate in urgency: soft alert, retry notice, access warning, final warning, suspension confirmation. Sending fewer risks missing the recovery window. Sending more without changing the message adds friction without value.
How soon should I send the first dunning email?
Within one to two hours of the failed charge. The window matters because many card failures are temporary: a bank hold, a low balance at billing time, a network error. Getting in front of the user while the issue is fresh and likely to resolve on its own is what makes early dunning emails effective.
What tone should dunning emails use?
Calm and transactional, especially in the early emails. Assume good faith. Most failed payments are not intentional. Blame or urgency language in the first email creates friction and resentment. The tone can become more direct in the later emails when access is about to lapse, but the frame should still be about helping the user keep their account, not threatening them.
What is the difference between voluntary and involuntary churn?
Voluntary churn is when a user actively cancels. Involuntary churn, sometimes called passive churn, is when an account lapses due to a failed payment and the user never deliberately chose to leave. Dunning sequences address involuntary churn specifically. The distinction matters because recovery rates for involuntary churn are much higher: the customer did not decide to leave, so a timely email can bring them back without any sales effort.
Can I automate a dunning email sequence with GetFluxly?
Yes. You fire a payment_failed event from your billing system or webhook, and GetFluxly triggers the sequence from that event. The automation handles the wait steps between emails, exits the sequence the moment a payment_succeeded event fires, and logs the outcome back to the customer profile. You bring your own ESP for delivery; GetFluxly drives the logic.