Why did my MRR drop? A 10-step checklist

This is a checklist for the moment the answer to "why did my MRR drop" isn't obvious from the chart. The order matters. The first checks are cheap and rule out drops that aren't real. The later ones take longer and find out who, specifically, the drop came from. Work through them in sequence and stop when the numbers add up.

1. Check that the data is complete

Before reading anything into a drop, make sure every source finished syncing.

• Last sync time per source. If Stripe synced this morning and RevenueCat hasn't synced since Thursday, your mobile MRR is stale, and depending on how your tool handles it, it may be missing.
• Webhook failures. If you build MRR from webhooks, look at delivery errors in your billing provider's dashboard. A deploy that broke your endpoint for a day can drop events silently.
• Revoked or rotated keys. A restricted API key that was rolled, or an integration someone disconnected, stops updates without an obvious error on your side.
• Definition changes. A fix to deduplication, a change of reporting currency, or a newly excluded plan can lower MRR overnight. That is a correction, not a loss, and it should be annotated as one.

If any of these turn up, fix the data and look again.

2. Compare equal-length periods

MRR at a point in time is a snapshot. The movements that change it (new, expansion, contraction, churn) are flows over a period, and flows depend on how long the period is.

February has three fewer days than January. A week with a public holiday has fewer working days than the one before it. Comparing net new MRR in February to January will show a dip even if every day was identical.

Compare 28 days with the 28 days before, or a week with the average of the previous four weeks. The average smooths out week-to-week noise.

3. Split the change into its movements

Net new MRR is the sum of five movements: new, expansion and reactivation, minus contraction and churn. A drop in MRR is always one or more of these, and each has different causes.

A hypothetical example:

Churn barely moved. What changed is that new MRR halved and no longer covers normal churn. That is an acquisition question, not a retention one. The post on net new MRR covers the movements in more detail.

4. Look at failed payments

Involuntary churn looks exactly like a customer leaving, and it is often the easiest to recover.

When a renewal payment fails, Stripe retries it on a schedule. During that time the subscription is past due, and most MRR definitions still count it. When the last retry fails, depending on your settings, the subscription is canceled, marked unpaid or left past due. If it cancels, all of that MRR turns into churn on one day.

Things to check:

• Past-due MRR over the last few weeks. A rise usually comes before a churn spike.
• Cancellation reason. On Stripe subscriptions, cancellation_details.reason separates cancellation_requested from payment_failed and payment_disputed.
• Expiring cards. Customers whose card expires this month are next month's failed payments.
• Mobile billing retry. App stores have their own billing retry and grace periods. RevenueCat reports those states, and they deserve the same attention.

5. Check for one large customer or one annual renewal

At small scale, one account can be the whole story. Sort this period's churned and contraction MRR by customer, largest first. If the top line accounts for most of the drop, you have a customer conversation to have, not a trend to analyse.

Annual plans create the same effect. A €1,200 yearly plan is €100 of MRR every month until the renewal date, and then it is either still €100 or zero. If a batch of annual customers signed up in the same month last year, their renewals land in the same month this year.

6. Think back to any price or plan change

Price changes move MRR in ways that are easy to forget a few weeks later.

• Migrating existing customers to a new plan or price creates expansion or contraction for every customer moved.
• An annual-plan promotion can lower MRR. A customer switching from €30 a month to €300 a year goes from €30 to €25 of MRR, even though they just committed for twelve months.
• A bulk coupon applied to existing subscriptions shows up as contraction.
• A new price for new customers only doesn't touch existing MRR, but it can change the new MRR line, in either direction.

Check your changelog and your coupon and price history for the period.

7. Rule out currency effects

If you bill in more than one currency and report in one, exchange rates can move MRR without any customer changing anything. A weaker dollar lowers euro-denominated MRR from dollar subscriptions.

How much this shows up depends on how you convert. Converting everything at today's rate means MRR moves every day with the market. Converting at a fixed rate per billing period keeps past figures stable and only lets currency in at each renewal. The approach is described in combined MRR for Stripe and RevenueCat. To test whether currency is the cause, recompute the change in each billing currency separately. If every currency is flat or up in its own terms, the drop is the exchange rate.

8. Check refunds and disputes

Under most definitions, a refund on its own doesn't change MRR, because MRR measures active subscriptions, not cash collected. But refunds rarely come alone. A customer who asks for a refund usually cancels in the same conversation, and that cancellation is churn.

Disputes are similar. Depending on your setup, a disputed payment can end with the subscription canceled.

If the drop is in a revenue or cash chart rather than MRR, refunds and disputes reduce it directly.

9. Consider seasonality

Some months are slower for reasons outside your product. If you sell to businesses, holiday periods can mean fewer purchasing decisions. If you sell to students, teachers or anyone with a yearly rhythm, their calendar is yours.

The test is the same period last year, if you have one. With less than a year of history, note the possibility but don't lean on it.

10. Find the segments that contributed

If the drop survived every check above, it is real, and the useful question becomes where it came from. Break the change down by:

• Plan. Is churn concentrated on one tier?
• Billing source. Web through Stripe, or mobile through the app stores?
• Country. A regional payment issue or a local competitor shows up here.
• First-touch channel. Faster churn from one channel suggests it sets expectations the product doesn't meet.
• First landing page. The same idea one level down: which page brought the customers who are now leaving.

For each segment, compute its contribution: the segment's change divided by the total change. Rank by that, not by the segment's own percentage change. A small plan that doubled its churn from €20 to €40 matters less than a large plan that went from €300 to €380.

Two cautions. Each dimension splits the same change, so contributions add up within a dimension, not across them: a customer on one plan who came from organic search appears in both lists. And with few customers per segment, a ranking can be driven by one account, which takes you back to step 5.

Where Joinsight fits

Joinsight's MRR drop alert compares the last seven days of churned MRR with the previous four weeks, and when it fires it names the plan, source, channel and landing page that contributed most. The same diff engine is available as the explain_change tool through the MCP server, which ranks segments by their contribution to the change. A separate data health alert and per-source sync freshness cover step 1.