Why you shouldn't rely solely on the Stripe dashboard for business health

Stripe's dashboard is genuinely good software. It's also not built to answer the question a SaaS founder actually cares about: is my recurring revenue healthy, and why. It's built to show you payments, which is a related but different question.

Four specific gaps, at a glance:

• Gross volume vs. MRR: Stripe shows gross volume and revenue totals; what's missing is true MRR, normalized from active subscription prices rather than invoice timing.
• Churn vs. contraction: Stripe shows one blended revenue drop; what's missing is knowing whether that drop was churn (lost the customer) or contraction (downgrade).
• History vs. forecast: Stripe shows historical totals only; what's missing is a forward-looking forecast based on current trajectory.
• Blended vs. isolated usage revenue: Stripe blends usage-based charges with subscriptions; what's missing is isolating metered revenue from your actually-predictable recurring revenue.

Example 1: gross volume isn't MRR

Stripe's dashboard surfaces gross volume and revenue totals for a given period. That number includes proration charges, one-off invoices, annual plans landing all at once, and refunds, all mixed together. Two months with identical MRR can show very different "revenue" totals in Stripe purely because of invoice timing.

Concretely: a company with a flat $20,000/mo MRR will still show a spike in Stripe's revenue chart in any month where a batch of annual plans happens to renew, because those renewals land as large one-time invoice amounts. The underlying recurring revenue didn't move at all; the chart just looks like it did. (See why real MRR isn't the same as invoice revenue for the normalization math that fixes this.) If you're reading Stripe's gross-volume chart as a proxy for recurring revenue health, you're reading noise.

Example 2: it doesn't separate churn from contraction

A customer who cancels and a customer who downgrades both reduce revenue, but they're different problems. Cancellation is churn: you lost the customer entirely. A downgrade is contraction: you kept them, just at a lower price point. Stripe's dashboard doesn't classify these separately by default.

Say MRR drops by $2,000 in a month. If that's 10 customers cancelling outright, you have a retention problem: something about onboarding, support, or fit is pushing people out entirely. If it's 40 customers downgrading from a $75/mo plan to a $25/mo plan, you have a different problem: those customers still see enough value to stay, but not enough to pay full price for the tier they were on. Lumping both into one "revenue down $2,000" line means a wave of downgrades looks identical to a wave of cancellations, when the right response to each is completely different, and this is exactly the kind of movement classification that per-plan visibility is built to surface.

Example 3: no forward-looking forecast

Stripe shows you history. It doesn't project where MRR is headed next month based on current trajectory and known upcoming events like trial expirations. That forecast is exactly the number a founder needs before making a hiring or spending decision, and it has to be built on top of the raw subscription data (current MRR, recent growth rate, and known upcoming trial conversions or expirations) rather than read off Stripe's dashboard directly.

A simple version of this forecast is just current MRR plus the average of the last few weeks' net daily movement, projected out to month-end. If MRR is $18,600 today and has been adding roughly $50/day net for the past two weeks, a linear projection puts month-end somewhere around $19,200. That's a rough number, and it should come with a confidence level based on how much data backs it up, but it's a materially more useful thing to look at before committing to a new hire than "here's what happened last month," which is all Stripe's dashboard can show you.

Example 4: metered and usage-based billing muddies the picture further

If any part of your business uses usage-based pricing, Stripe's revenue charts blend that in with your actually-recurring subscription revenue. Usage-based charges aren't guaranteed next month the way a fixed subscription price is: a customer who ran a lot of API calls this month might run far fewer next month with no cancellation or downgrade event at all. Treating them the same in a "recurring revenue" chart overstates how predictable your revenue really is, and it means a genuinely flat subscription base can look like it's growing or shrinking purely based on usage-driven noise.

So what should you actually check every morning?

None of this is a knock on Stripe: it's not trying to be a SaaS metrics product, and it's excellent at being a payments platform. But it means the dashboard you open every morning to answer "is the business healthy" needs to compute MRR from actual subscription prices, classify movements (new, expansion, contraction, churn, reactivation) explicitly, and project forward, none of which is what Stripe's own dashboard is designed to show you. In practice that's three things: real MRR (not gross volume), a movement breakdown (not one blended delta), and a forecast (not just history).

Gleam Revenue computes all four of these directly from your Stripe data: real MRR, churn split from contraction, a forward-looking forecast, and metered revenue isolated automatically. Start your free trial →