Blog

How to detect churn risk from Stripe data

What your Stripe account can tell you about churn before it happens, what it can't, and a step-by-step way to build an at-risk list — with or without product usage data.

Author

Vinicius Aguiar

Published

Sep 23, 2026

Reading time

4 min read

Short answer: Stripe shows churn risk in four places — failed payments, downgrades, subscriptions set to cancel at period end, and trials ending without a payment method. Those catch customers who are already leaving. To catch them earlier, you have to join Stripe with product usage: a customer who still pays but stopped using the product is the risk Stripe alone can't see.

This guide walks through both: what to pull from Stripe, and how to add usage so the list shows up weeks before the cancellation does.

What Stripe can tell you on its own

Stripe is a record of money, not of behavior. Everything it knows about churn risk is a billing event. That still covers a lot.

Churn signals available in Stripe's API, and what each one means.
—	Where to find it	What it means
Failed payment	invoice.payment_failed event; subscription status past_due	Involuntary churn in progress: the customer may want to stay, the card didn't.
Cancel at period end	cancel_at_period_end = true on the subscription	The customer already decided. You have until the period ends to change their mind.
Downgrade	customer.subscription.updated with a lower price	Contraction — often the step before a cancellation.
Trial ending without a card	customer.subscription.trial_will_end; no default payment method	The trial is about to lapse into nothing.
Cancellation	customer.subscription.deleted	Churn that already happened. Useful for the post-mortem, too late to prevent.

If you do nothing else, alert on these five in the channel your team already reads. A failed payment seen the same day is usually an expired card and one email. The same failure seen at the end of the month is a lost customer.

What Stripe can't tell you

The most expensive churn has no billing event before the cancellation. The customer pays on time, every month, while their team logs in less and less — or never really started. Stripe sees a healthy subscription right up to the day it's deleted.

That's the gap: billing tells you who is paying; usage tells you who is getting value. Churn risk lives where the two disagree.

Step by step: build an at-risk list from Stripe plus usage

Step 1: List paying customers with their MRR

From Stripe, take every subscription in status active, trialing, or past_due, and normalize each price to a monthly amount (an annual plan at $1,200 is $100 of MRR). Keep the customer id and email — you'll need both to match.

Step 2: Pull usage per customer

From your product analytics (PostHog, Mixpanel, Amplitude) or your own database, get two numbers per user or account: activity in the last 7 days, and activity in the 7 days before that. Also keep the last date each one was seen.

Step 3: Match usage to billing

Join the two lists. Matching by email works when the person who pays is the person who logs in. In B2B, one company pays and several people sign in with different addresses — so match by company domain as well, or send the Stripe customer id from your backend with each event.

Report the match rate. An at-risk list built on 60% of your customers is a different thing from one built on 95%, and the reader should know which one they're holding.

Step 4: Flag the patterns

Three patterns cover most silent churn:

Dropped: activity in the last 7 days fell sharply against the 7 days before.
Silent: a paying customer not seen for a number of days you choose (two to three weeks is a reasonable start for a product used weekly).
Never active: a paying customer with no usage at all since signing up.

A ratio can't see the third one. Last week's usage divided by the week before is 0 ÷ 0 for a customer who never logged in — no drop to detect, so a drop-based alert never fires.

Step 5: Rank by money, not by severity

Sort the flagged accounts by MRR. A 90% usage drop on a $30/month account is a smaller problem than a 40% drop on a $3,000/month account. The list your team works from should start with the biggest number.

Step 6: Put a date and an owner on each one

Add the next renewal date from Stripe and the account owner from your CRM. Risk with a renewal in six days is this week's job; risk with a renewal in eleven months is a note for the quarterly review.

A quick way to check your own numbers

Before building anything, run the count once:

paying customers with zero usage in the last 30 days × their MRR

It's the size of the revenue that is technically retained and practically gone. Most teams have never calculated it.

Doing it without building it

The steps above are what Keep does: it reads Stripe through Stripe Connect, reads usage from PostHog or an activity API, flags accounts that dropped, went silent, or never started, and posts each one to Slack with the MRR at stake, the renewal date, and the owner from HubSpot. It never changes anything in Stripe.

FAQ

Can Stripe predict churn?

Not directly. Stripe exposes billing events — failed payments, downgrades, scheduled cancellations — which signal churn that is already under way. Predicting it earlier requires product usage, which Stripe doesn't have.

What's the difference between churn risk and churn?

Churn is a cancellation that happened. Churn risk is a paying customer showing the signs that usually come before one: fading usage, a failed payment, a downgrade, or no usage at all.

How far back does Stripe keep events?

Stripe's events API returns roughly the last 30 days. To analyze subscription changes over longer periods, you need to store them yourself as they happen.

What's a good threshold for "silent"?

It depends on how often a healthy customer uses the product. For a tool used daily, a week of silence is meaningful; for one used weekly, two to three weeks is a safer start. Tune it against the accounts that actually churned.