13
15 Comments

Most dashboards show MRR. None show how much left through failed payments.

you open your dashboard.

MRR: $10,200
Active subs: 127
Churn: 6.2%

looks fine. maybe churn is a little high, but you've seen worse.

then you check stripe logs.

8 payment failures this week. 3 cards expired. 5 more in retry. 2 downgrades that turned into cancels 9 days later.

suddenly that 6.2% has a story. and half of it wasn't people leaving — it was billing breaking quietly in the background.

the invisible half of churn

most dashboards show you one number: total churn.

what they don't show:

  • how much was involuntary (failed payments, expired cards, bank declines)

  • how much was voluntary (people who clicked cancel and left)

those are completely different problems.

one is a product issue. the other is a billing infrastructure issue.

but because they're lumped into the same metric, founders spend weeks fixing onboarding when the real leak is in stripe's retry queue.

what the split actually looks like

here's what we see when we break it down:

at $10k MRR, typical monthly churn = $600–$1,200

of that:

  • 20–40% is involuntary (cards failing, expirations, declines)

  • 60–80% is voluntary (conscious cancellations)

so $120–$480/month is leaking through payment infrastructure alone.

over a year: $1,440–$5,760 you could have recovered if you'd caught it in the first 24–48 hours.

most founders never see that breakdown.

stripe already knows. your dashboard doesn't.

stripe fires events for every moment that matters:

  • invoice.payment_failed → payment declined

  • customer.source.expiring → card expiring in 30 days

  • customer.subscription.updated → downgrade (often a pre-cancel)

  • payment_method.detached → card removed

it's all logged. all timestamped.

but it lives in webhooks and logs, not dashboards. and after ~30 days, it starts to fade.

so when you look back at last month's churn spike, all you see is the line going down — not the story of what caused it or how much was saveable.

the question most founders can't answer

if your MRR dropped last month:

  • how much was failed payments?

  • how much was people choosing to leave?

  • how many failures could you have recovered if you'd known in time?

if the answer is "i don't know," you're solving churn blind.

what recurflux shows instead

recurflux connects to stripe and surfaces the split your dashboard hides:

  • involuntary vs voluntary churn — see the real breakdown

  • who's in dunning right now — customer, plan, retry count, time left

  • downgrades that became cancels — and how fast it happened

  • trials that expired with zero intervention — missed opportunities

instead of "churn was 6.2%," you see:

  • "$240 failed in retries"

  • "3 downgrades → cancels within 2 weeks"

  • "12 trials ended, 0 emails sent"

suddenly the fixes are obvious.

one question

can you tell me right now how much of your churn last month was failed payments vs people choosing to leave?

if not — that's the gap recurflux fills.

https://recurflux.com/

posted toAvatar for product Recurflux
Recurflux
  1. 1

    This is actually a really smart breakdown.

    I think a lot of founders treat churn like a single “product problem” when in reality failed payments and voluntary cancellations are completely different fires to solve.

    The “MRR has a story behind it” point is especially good. Most dashboards show the number after the damage already happened, not the chain of events that caused it.

    Feels like one of those problems people massively underestimate until revenue quietly starts leaking.

    1. 1

      Exactly. treating all churn the same is the mistake — failed payments need dunning, voluntary needs retention/product work.

      most don't realize how much is leaking from billing until they run the numbers. zero product changes needed to fix it.

  2. 1

    This is one of those invisible leaks that quietly kills SaaS growth. Failed payment recovery deserves way more attention than vanity metrics honestly

    1. 1

      100%. it's the boring stuff that actually moves revenue, but nobody wants to talk about billing infrastructure when they could be optimizing landing pages.

      failed payment recovery is unglamorous work with glamorous results.

  3. 1

    The downgrade-as-pre-cancel insight is the most underrated metric in subscription SaaS. Most founders treat a downgrade as a save and stop the conversation. In our data, a downgrade is the start of a 30-day decay curve, not the end of one. If you can surface the "downgrade to cancel within 14 or 30 days" rate alongside dunning, founders see it as a forecasting tool, not just recovery. Worth its own dashboard.

    1. 1

      This is a completely different lens — haven't seen downgrades framed this way before.

      we've been treating them as neutral or even positive (retained customer, lower MRR). but if it's the start of a 30-day decay curve, the real metric becomes "downgrade-to-cancel rate within 30 days."

      suddenly it's not a save, it's a leading indicator. forecast it and you can intervene before cancel.

      are you tracking this as a separate cohort or building a decay model? curious how you're surfacing it to make it actionable.

  4. 1

    This is a really interesting point about failed payments. Most tools hide the ugly reality. How are you tracking that on your end?

    1. 1

      We track it through the payment processor webhooks — every failed payment, decline reason, retry attempt, and recovery gets logged in real time.

      most dashboards don't surface it clearly because it's not a feel-good metric, but it's one of the biggest silent revenue leaks for subscription businesses.

      what are you using right now to monitor yours?

  5. 1

    Nice idea, for my saas reetro, i have the exact same problem, failed payments, expired cards and insufficient funds, this could be a good tool to recover lost MRR. I will try this out. I think, not me but everyone who has to integrate his stripe with a third party tool will have some doubts, how you handle the access, what u can see and not see etc. Your security page https://recurflux.com/security is a bit shallow, not a pitch but i will be happy to give you full access to https://sekorti.com so you can setup a full fledged trust center and list all the controls etc.

    1. 1

      Appreciate you trying it out and the feedback.

      the security page could definitely be more detailed - that's fair. though we do show stripe scopes and permissions pretty clearly in the onboarding flow itself, so it's not like it's hidden.

      that said, the sekorti offer is interesting. hadn't seen a tool like that before. i'll definitely check it out and reach out.

      also - would love to help you set up recurflux for reetro and see how it works for your failed payments. happy to walk you through it or answer anything that comes up.

      thanks for the heads up.

  6. 1

    Nice idea!!

    But as i was exploring Recurflux and noticed something interesting about their positioning.

    The product is powerful, it helps recover failed subscription revenue, but the mental model feels slightly overloaded because multiple systems (retry engine, dunning, analytics, win-back) are introduced at once.

    This creates a small clarity gap for first-time visitors who may not immediately understand what the core value is.

    A potential improvement could be reframing the product around a single concept like a “Revenue Recovery Engine” or even a live “recovery feed” that visually shows money being recovered in real time.

    This would make the value instant and more emotionally engaging for founders who are already worried about churn.

    1. 1

      this is really valuable feedback, thank you for taking the time to dig in and write this out.

      you're right that we're presenting multiple systems at once (retry, dunning, analytics, win-back), and that can create cognitive load before the core value lands.

      the "revenue recovery engine" framing is a great angle - making it feel immediate and visual instead of feature-heavy. i'm going to work through how we can simplify that first impression around one clear concept.

      appreciate this - if you spot anything else as you look around, would love to hear it.

      1. 1

        Glad it resonated, honestly the core problem/value is already strong, which is why the positioning stood out to me.

        One thing I also noticed is that the product feels most compelling when the user can immediately visualize “money being recovered” instead of processing multiple systems first.

        Even something as simple as a live recovery activity feed or timeline near the hero could make the experience feel more tangible and emotionally immediate for founders.

  7. 1

    This is actually a really important breakdown. Most dashboards really hide the “why” behind churn. Involuntary churn is often overlooked.

    1. 1

      Yeah, and it's usually 20–40% of total churn sitting in retry queues nobody's watching.