BugOtter
Sign inStart free trial

Guide · Metrics

SaaS metrics in plain words

MRR is what your subscriptions bring in each month, churn is the share you lose, and net revenue retention says whether the customers you already have grow or shrink. This guide gives each metric a plain definition, a formula, a worked example with small numbers, and the mistake people usually make.

9 min read

The otter counting on an abacus

Money: MRR, ARR, ARPU, LTV

  • MRR is monthly, not cash

    The monthly value of active subscriptions. A yearly plan counts a twelfth; one-time sales and unpaid trials don’t count.

  • Measure from the start

    Churn and NRR divide by what you had at the start of the period, and leave new customers out.

  • Quality moves first

    Errors, outages and slow pages show up a week before the money does.

These four describe the size of your subscription business right now. They’re snapshots: each one is true for today and changes with every signup and cancellation.

$116

The example app on this page: 8 customers on a $12 monthly plan and 2 on a $120 yearly plan.

All the money examples use it, so you can follow one set of numbers from MRR to lifetime value.

MRR (monthly recurring revenue)

Sum over paying subscriptions of price ÷ months in its billing period. Yearly plans count a twelfth.

Worked example
8 × $12 = $96. 2 × ($120 ÷ 12) = $20.
MRR = $116
In plain words
What your active subscriptions bring in per month, with every plan converted to a monthly amount.
Common mistake
Counting a yearly payment as $120 of MRR in the month it’s paid, which makes MRR spike and crash. Also counting one-time purchases, or trials that haven’t paid yet.
In BugOtter
The Revenue page, per app and across apps, in each currency (never added together). Counts active and past-due subscriptions, normalized to a month, the same way Stripe defines it. Trials don’t count until they pay. Try the numbers in the MRR calculator.

ARR (annual recurring revenue)

MRR × 12

Worked example
$116 × 12
ARR = $1,392
In plain words
MRR as a yearly figure: what a year looks like at today’s pace.
Common mistake
Calling the last 12 months of total revenue “ARR”. That number includes one-time sales and customers who already left. ARR is forward-looking and recurring only.
In BugOtter
Next to MRR on the Revenue page, labelled “MRR × 12: a year at today’s pace.”

ARPU (average revenue per user)

MRR ÷ paying subscribers

Worked example
$116 ÷ 10 paying subscribers
ARPU = $11.60 a month
In plain words
What one paying customer is worth per month, on average.
Common mistake
Dividing by every signed-up user, including free and trial accounts. That’s a different (and much smaller) number. Say which one you mean; for SaaS, per paying customer is the useful one.
In BugOtter
On the Revenue page as “MRR per paying subscriber.”

LTV (lifetime value)

ARPU ÷ monthly churn rate (the simple version, no discounting).

Worked example
ARPU $11.60, monthly revenue churn 5% → $11.60 ÷ 0.05
LTV = $232
In plain words
Roughly how much a customer pays you before they leave.
Common mistake
Computing it from a week of data, or a month with no churn (dividing by zero gives “infinite” LTV). It’s only meaningful with a full month or more of movements.
In BugOtter
On the Revenue page. It stays blank and says why (pick 30 days or more, or not enough history) rather than show a guess.
BugOtter’s Revenue page: MRR $1,389 with $16,662 a year, the How MRR moved waterfall (new, upgrades, downgrades, cancelled), a forecast, and revenue, paying subscribers and trials
  1. MRR, with ARR next to it as “a year”.
  2. How MRR moved: new, upgrades, downgrades and cancelled. The parts of churn and NRR.
  3. Paying subscribers and what each pays per month: ARPU.
  4. Trials in progress and the MRR they’re worth if they pay.
The live demo’s Revenue page. Each number here is one of the cards on this page.

Keeping customers: churn and NRR

Growth is new customers minus the ones you lose. These metrics measure the losing part, and whether the customers who stay spend more over time.

Example for this section: at the start of the month, 50 customers paying $1,000 MRR. During the month:

  • 3 cancel ($60 of MRR).
  • 1 downgrades from $29 to $12 ($17 less).
  • 2 upgrade ($45 more).
  • 6 new customers join ($90).

Churn: logo churn and revenue churn

Logo churn = customers lost ÷ customers at the start. Gross revenue churn = (MRR lost to cancellations + downgrades) ÷ MRR at the start.

Worked example
Logo churn = 3 ÷ 50. Revenue churn = ($60 + $17) ÷ $1,000. The 6 new customers aren’t in either formula.
6% logo churn · 7.7% revenue churn
In plain words
The share of customers (logo churn) or of MRR (revenue churn) you lost in a period. Revenue churn counts downgrades too, not just cancellations.
Common mistake
Dividing by customers at the end of the month (new signups hide losses), or comparing a 7-day churn with a monthly one. Always use the start of the period as the base, and the same period length.
In BugOtter
The Revenue page shows churn as the share of MRR lost to cancels and downgrades, with the share of subscribers who left next to it. It needs MRR history from the day before your range starts; before BugOtter was watching, cancellations weren’t seen, so it says so instead of guessing.

NRR (net revenue retention)

(MRR at start + expansion − contraction − churn) ÷ MRR at start. New customers are left out. Gross revenue retention (GRR) is the same without expansion, so it can’t go over 100%.

Worked example
NRR = ($1,000 + $45 − $17 − $60) ÷ $1,000. GRR = ($1,000 − $17 − $60) ÷ $1,000.
96.8% NRR · 92.3% GRR
In plain words
Of the money your existing customers paid at the start, how much they pay now. Over 100% means upgrades outweigh what you lost, so you’d grow even with zero new customers.
Common mistake
Adding new customers’ MRR. Then NRR measures growth, not retention, and a big launch month makes a leaky product look great.
In BugOtter
Not shown as one number yet. The Revenue page shows the parts for any range: MRR, then new, upgrades, downgrades and cancelled. Take MRR at the start of the range from the chart and use the formula.

Trials: conversion

Trial conversion rate

trials that converted ÷ trials that ended, for trials that started in the same period (a cohort).

Worked example
40 trials started in October. By mid-November, 31 have ended and 7 of those paid: 7 ÷ 31. Dividing by all 40 gives 17.5%, which is wrong while 9 are still running.
22.6% trial conversion
In plain words
Of the trials that have ended, the share that became paying customers.
Common mistake
Counting trials that are still running as failures, or mixing trials that needed a card with ones that didn’t. Card-required trials convert at a much higher rate, and from a smaller group.
In BugOtter
The Revenue page shows trials in progress (and the MRR they’re worth if all pay) and trials that turned into a paid plan while BugOtter was watching. It doesn’t show a conversion rate: payment providers don’t report trials that end without paying, so the denominator isn’t known.

Quality: crash-free, uptime, speed

Money metrics tell you what happened. These tell you why, often a week before the money does: people who hit errors, outages and slow pages leave quietly.

Crash-free sessions and crash-free users

Crash-free users = (users − users who hit a crash) ÷ users. Same for sessions.

Worked example
2,000 visitors this week, 30 hit an unhandled error: (2,000 − 30) ÷ 2,000
98.5% crash-free users
In plain words
The share of sessions not ended by a crash, and the share of people who didn’t hit one. On the web, where pages rarely “crash”, people use the same idea with unhandled errors.
Common mistake
Letting one noisy error you can’t fix (a browser extension, a bot) sink the number. Also comparing session-based rates across apps: in single-page apps some tools count every navigation as a session.
In BugOtter
BugOtter doesn’t use the name. Its Analytics page has “Hit an error”: the share of visitors who hit a browser error. 100% minus that is your crash-free (error-free) visitors. It splits by source, page, browser and country, and the Errors page has release health: errors per hour since a release vs before, new errors and ones that came back.

Uptime percentage

checks that passed ÷ all checks, or minutes up ÷ minutes in the period.

Worked example
30 days = 43,200 minutes. Down for 45 minutes: 43,155 ÷ 43,200. For scale, 99.9% allows 43 minutes a month, 99% allows 7 hours 12 minutes.
99.896% uptime
In plain words
The share of time your app was working, as seen from outside.
Common mistake
Trusting a single checker in one region (its network problems count as your downtime), or checking every 5 minutes and assuming short outages didn’t happen.
In BugOtter
30-day uptime per app on Home and the Uptime tab, from checks in three regions that only count as down when two agree. 90 days on the public status page. The uptime calculator turns any percentage into minutes.

Core Web Vitals: LCP, INP, CLS

Google’s “good” thresholds: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1, measured at the 75th percentile of real page loads, mobile and desktop separately.

Worked example
100 page loads, sorted by LCP. If 70 are under 2.5 s and 30 are slower, the 75th load is over 2.5 s, even though the median looks fine.
The page fails LCP
In plain words
LCP: how long until the main content shows. INP: how fast the page answers a click or tap. CLS: how much the page jumps around while loading.
Common mistake
Reading a Lighthouse score as your Core Web Vitals. Lighthouse runs once, in a lab, on a fast machine. The thresholds apply to real users at the 75th percentile, which is usually slower.
In BugOtter
BugOtter’s script measures LCP, INP and CLS on real visits. Today the Analytics Read tab shows median LCP per page, labelled fast (2.5 s or less), ok (up to 4 s) or slow. INP and CLS are collected but not shown on their own yet. A median is kinder than Google’s 75th percentile, so treat “ok” as a warning.

Sources

Definitions checked on Nov 4, 2026:

Questions

What’s a good churn rate for a small SaaS?

It depends on price and customer type. Cheap tools bought by individuals often lose several percent of customers a month; tools sold to companies on yearly plans lose far less. Compare your churn with your own last quarter before comparing it with anyone’s benchmark.

Is MRR the same as revenue?

No. MRR is the monthly value of active subscriptions right now. Revenue is money actually received in a period, including one-time payments and minus refunds. A yearly plan adds its full price to revenue in the month it’s paid, but only a twelfth to MRR.

Should I track NRR with only 30 customers?

You can, but read it over a quarter or more. With few customers, one upgrade or one cancellation moves it by several points.

Why does my Core Web Vitals report differ from Lighthouse?

Lighthouse is a lab test on one machine. Core Web Vitals in Search Console come from real Chrome users at the 75th percentile. INP can’t be measured in a lab at all, because it needs real interactions.

Your MRR, churn and uptime, next to each other.

14 days of everything, no card needed. Plans from $10 a month, billed yearly.

Start free trialSee the live demo