How to monitor MRR in real time

What monitoring MRR really means

Monitoring MRR means watching your monthly recurring revenue and the movements that change it, closely enough that you learn about a meaningful move while you can still do something about it. Most people reduce it to a single line on a chart that goes up and to the right. That line is worth having, but on its own it tells you the score without telling you the game. A total that ticks up a little can be hiding new revenue papering over churn; a total that dips can be a routine downgrade or the leading edge of a billing problem. The total cannot tell the difference. The movements can.

So the honest definition of "monitoring MRR" is not "keep a chart of the number." It is "keep the number, keep the five movements that produce it, and — the part almost every tool stops short of — keep a path from any movement back to the customer and the cause behind it." The first two are widely available; the third is the subject of the back half of this guide, and it is where monitoring stops being a passive habit and becomes something you can act on.

How MRR is calculated

MRR is the sum of every active recurring subscription, each normalised to a monthly figure. An annual plan of $1,200 counts as $100 of MRR; a quarterly plan of $300 counts as $100; a straightforward $49-a-month plan counts as $49. You add those normalised values across all active subscriptions and that is your MRR. (All figures here are illustrative.)

Two exclusions matter. First, one-off charges are not MRR — a setup fee or a single purchase is real revenue but does not recur, so it does not belong in a recurring-revenue number. Second, taxes and processor fees are not MRR — MRR is measured on the plan value, not on what nets into your account. This is why MRR will never match your Stripe payout or your bank deposits: MRR is a run-rate that describes the shape of your recurring business, while cash is what actually arrived, on its own timing. Conflating the two is the most common MRR mistake. The fuller treatment of why recognised revenue and banked cash diverge is in the complete guide to app revenue intelligence.

The five movements that move MRR

If you monitor one thing beyond the total, monitor the movements. Every change in MRR is one of five movements, and the net number you usually stare at is the sum of all of them fighting each other — which is why the net is such a poor teacher: it collapses five distinct stories into one line and hides which is winning.

Net new MRR ties them together: new plus expansion plus reactivation, minus contraction and churn. The reason to watch the parts rather than only this net is the classic trap — two businesses can report identical net new MRR while one compounds healthily on expansion and the other loses customers steadily and back-fills the hole with expensive new sales. The net says they are the same; they could not be more different. Churn and contraction are where the warning lives, and they are precisely the movements a top-line chart is built to smooth over.

How people monitor MRR today

There are three genuinely reasonable ways to track MRR right now, and none is wrong. The right choice depends on how many rails you are on and how much you want to maintain. Here they are, named fairly, with each trade-off.

Stripe's own reporting. If you bill through Stripe, its Billing dashboard reports MRR and its movements directly, and Stripe Sigma lets you query the underlying data. This is the closest-to-source option and free with the account. The limitation is scope: it sees Stripe. If your app also earns on Apple and Google, Stripe's MRR is one rail of a multi-rail number, and you are back to stitching the rest together elsewhere.

A dedicated MRR dashboard. Tools like Baremetrics, ChartMogul and MRR.io connect to your billing and present MRR, the five movements, cohorts, retention curves and forecasts without you building anything. They are well-made and, for many teams, the sensible answer — a proper subscription-analytics view in an afternoon. The trade-offs are cost as you grow, and that they are a revenue layer: they explain the number thoroughly but stay within it.

A spreadsheet from a CSV export. The oldest option, and still good when you are small. Export subscriptions to CSV, normalise the plans to a monthly figure, and sum. Templated pulls via Databox or Coefficient can keep a Google Sheet refreshed, so it is less manual than it sounds. You own it completely and it costs nothing but time — plus the fragility, since a spreadsheet is only as current as its last refresh and normalisation errors creep in quietly.

Read down the last column. All three tell you that MRR moved and by how much; none, by design, tells you the customer behind the move or the reason for it — because each is a revenue tool, and the reason usually lives in a different layer entirely.

The gap: the number without the cause

Here is the moment every founder who has monitored MRR knows. The number dips. Say it drops by a couple of thousand overnight. Your dashboard shows the dip cleanly, attributes it to churn, and stops there. You now know MRR fell and that a cancellation caused it — and you know nothing about which customer, or why they went. The dashboard has told you the score changed and left you to open three other tools to find out what happened.

So the investigation begins: the billing tool to find the cancelled subscription, the CRM to see who they were, the error monitoring to check whether they hit a failure. And often — often enough that it should change how you think about MRR — you find the churn was not a decision at all. The customer hit a checkout error or a failed renewal, could not complete the payment, and left. The MRR drop was the last event in a chain that started with an error, and your revenue dashboard could see only the final link.

This is the structural gap, stated plainly: a dashboard shows you that MRR moved; it rarely shows you, in the same view, the customer who moved it and the cause behind the move. That is not a flaw in any product — Baremetrics, ChartMogul, MRR.io and Stripe's own reporting all do their job accurately. It is that the answer to "why" lives across three layers — revenue, identity, and errors — and a single-layer revenue tool holds only one. The number and its cause are separated by the exact join no MRR dashboard was built to make. We wrote about the sharpest version of this — a paying customer hitting an error at the worst moment — in how to know when a paying customer hit a checkout error.

MRR joined to its cause

The fix for that gap is not a better chart. It is a join. Crossdeck is the app intelligence layer: it monitors revenue across rails — Apple, Google, Stripe — and joins each MRR move to the customer behind it and to any error on that customer's timeline, by identity. That join is the cross-match, and it is the difference between a number that moved and a number that arrives with its explanation attached. When MRR dips, you are not handed a figure to go investigate; you are handed the churned customer and the error that preceded their churn, on one timeline, in one view. The contrast is easiest to see side by side.

To be careful about the claim: this is the intelligence layer plus its delivery, not a full BI suite, and every figure is read from your live Crossdeck data rather than estimated. What it does is hold revenue, identity and errors in one hand, so "why did MRR move?" has an answer where the move appears. For the wider pattern this sits inside — monitoring the whole business in real time, not one metric at a time — see the hub guide, real-time business monitoring.

Monitoring MRR from your phone

Once MRR is joined to its cause, where you read it matters less. You do not need to sit in front of a dashboard to monitor MRR; it can reach you where you already are. Crossdeck delivers the joined view to Telegram, in private chat, three ways.

• The Mini App shows your MRR and its trend from your phone — the current figure and which way it is moving. Sign in to the dashboard with Telegram; it is the same live figure the web view shows.
• Hard-data commands. Ask /revenue and the bot replies with your live MRR and recent trend on demand — the fastest way to check the number: a message, an answer, no tab.
• Prism, for the "why". This is the part a dashboard cannot do from your pocket. Ask in plain English — "is MRR down this week, and is it tied to an error?" — and Prism answers off your live numbers, joining the revenue move to the customers and errors behind it.

One honest note on Prism, because it matters: Prism runs on your own AI model, with your own key, connected once in the Prism tab. It is your model reasoning over your live Crossdeck data — Crossdeck does not run an AI on your data or train on it. Connect a model first, and from then on you can ask MRR questions in words. The alerts, Mini App and commands work in private chat today; shared team and group chats are on the roadmap, not shipped yet. The setup walk-through lives in getting Stripe error alerts in Telegram, and you can see Prism itself at cross-deck.com/prism.

MRR alerts and real-time MRR

MRR alerts. An alert is a message when MRR moves in a way worth knowing about — a cancellation, a large downgrade, a failed renewal, or a run of them. Most tools can send a threshold alert or a daily summary, which is genuinely useful. But a plain threshold alert hits the same gap as before: it tells you the number moved, not who moved it or why, so it lands as a notification rather than the start of a fix. An alert earns its interruption when it names the customer behind the drop and the error, if any, that preceded it — only possible when the alert is fired from joined data. The sibling guide error alerts that name customers is the focused treatment of that idea.

Real-time MRR is real, with one honest caveat: it is only as fresh as the slowest rail feeding it. Stripe events arrive quickly, so Stripe MRR sits close to live. App-store revenue from Apple and Google is reported on the store's schedule, so a truly real-time cross-rail MRR is bounded by that lag — and any tool claiming otherwise is estimating. Crossdeck surfaces the current figure on demand and is clear about which rail is live and which is lagged, rather than presenting a smoothed guess as fact. The neighbouring problem — seeing app revenue before the store's console catches up — is covered in seeing app revenue in real time before App Store Connect catches up.

Tracking MRR without a dashboard

Plenty of founders would rather not add another tool to log into, and that is legitimate. You can track MRR without a dashboard by having the number come to you instead of going to it. The spreadsheet route is one version — a CSV export normalised in a sheet, refreshed on a schedule. The lighter version skips the sheet and the tab entirely: ask /revenue in Telegram, glance at the Mini App for the shape of it, and ask Prism when you want more than the number. The monitoring still happens — but the interface is a message thread you already check all day. For a lean team, "no dashboard" often just means "the dashboard comes to me."

How to start monitoring MRR well

You do not need to rebuild your stack to monitor MRR properly. Start where you are and add the missing layer.

1. Pick your source of truth. If you are Stripe-only, Stripe's own reporting is a fine baseline. If you are on Apple and Google too, decide early how you will get one MRR across rails rather than three partial ones.
2. Watch the five movements, not just the total. Split MRR into new, expansion, contraction, churn and reactivation from day one. If your tool only shows the net, that is the first thing to fix — the net is where the warning hides.
3. Decide what a meaningful move is. Set the threshold that deserves an alert — a churn above some amount, a run of failed renewals — so you are interrupted by signal, not noise.
4. Close the gap to the cause. Make sure a move can be traced to the customer and to any error behind it — the join a revenue-only tool cannot make, and the difference between knowing MRR fell and knowing why.
5. Put it where you'll see it. A number you check beats a dashboard you don't. Whether that is a browser tab or a /revenue message in Telegram, choose the surface you actually look at.

Monitoring MRR is easy to do shallowly and valuable to do properly. The shallow version is a line on a chart; the proper version is the five movements, across every rail, with each move joined to the customer and the cause behind it — the number arriving with its explanation. That join is the whole difference between watching MRR and understanding it.

Frequently asked questions