What is MRR at risk, and how do you calculate it?

MRR at risk is the monthly recurring value of subscriptions that are currently showing signs of being lost: payment failing, set to cancel at period end, or with a latest invoice that is failing. It is a snapshot of today, not a forecast, and not all of it will be lost. Here is how I count it and what to do with the list.

What is MRR at risk?

It is a present-tense number. Instead of asking what you lost over the past year, it asks which paying customers are in trouble right now, and what they are worth per month. That makes it the most actionable figure in the report, because every item on it is a person you can still reach.

The history numbers, such as failed payments never recovered or voluntary cancellations, tell you where money went. This number tells you where it may go next.

Which subscriptions count?

Three kinds, each with a plain reason:

• Payment failing: the status is past due or unpaid.
• Cancels at period end: the subscription is active but already set to end when the current period finishes.
• Last invoice failing: the status is active, but the latest invoice is open and its first attempt failed.

Each subscription is valued at its monthly recurring value, the same as everywhere else: list price times quantity, normalised to a month. The total is the figure, and I also show it as a share of active recurring revenue. In my synthetic sample, for a fictional company, it is $3,508 a month, or 4.4% of $80,330. Those figures are made up.

Why call it a snapshot, not a forecast?

Because I do not know how many of these will be lost. A card that is failing may recover next week. A customer who has set the subscription to cancel at period end may be saved. If I multiplied the total by a loss rate, I would be inventing a loss rate. I have no sourced rate, so I do not.

What the number gives you is a ceiling for the short term and a list for action. It is a better reason to get on with the work than an average.

Does it include trials?

No. Trials still running are not paying yet, so they are not at risk in this sense. I report the value of trials ending within the next 14 days separately: $1,233 a month in the sample, again synthetic. Those are the trials where a reminder about the card and the first charge is still possible.

For the longer-run view of trials, see how to calculate trial-to-paid conversion.

What do I do with the list?

1. Payment failing: send the one-click card-update message first. These customers have not decided anything yet. The steps are in how to recover failed payments on Stripe subscriptions.
2. Cancels at period end: this is a decision already taken, but there is still time before the end date. Ask the reason and offer the matching lever, as in a reason-first cancel flow.
3. Last invoice failing: watch it. If the retry schedule finishes with nothing, it will move into the first group.

Start with the largest values. In the report I list the largest at-risk accounts so that you do not have to sort a spreadsheet.

Are the email addresses visible?

In my report they are masked, showing only the first character of the name and of the domain, so the PDF is safe to forward inside a company. If you want to act on specific accounts, the details are in your own Stripe dashboard, filtered by status.

What are the limits?

• It counts only what Stripe can see. A customer who has told you by email that they are leaving does not show up.
• The list can include customers who will recover without any help, so it overstates what you can influence.
• Values are list price, not what is collected after coupons.
• Currencies other than USD are excluded unless we agree a rate.

I list the same limits on page two of every report, next to the number they apply to.

How often should I check it?

Often enough to act. Because it is a snapshot, a weekly look is more useful than a quarterly one. The weekly report in my pilot is in dollars, treated group against holdout. For a small account, a weekly filter of past-due and set-to-cancel subscriptions in Stripe gives you most of it by hand.

What should I write down when I report it?

The date, the total, the share of active recurring revenue, and the split by reason: payment failing, set to cancel, last invoice failing. In my sample the split is what tells you where to act first. Without the date the number means nothing, because a snapshot ages quickly. I also write the count of accounts, since ten accounts at $199 and one account at $1,990 call for different handling.

How is it different from the headline?

The headline is the realised leak per month, averaged over the window. MRR at risk is a point in time. The two answer different questions and should not be added together. One says what you lost, the other what could be lost soon. The base figure for both is explained in how to calculate MRR from Stripe.

You get both in the Revenue Leak Report: $490, within 48 hours of my having a restricted read-only Stripe key.