Sentry Session Replay Pricing: When the Per-Replay Math Stops Working

Sentry session replay pricing is usage-based: replays are a separate billable unit on top of your errors quota, with a modest included allowance on paid plans and per-replay charges (or reserved volume) beyond it — per their public pricing pages, as of mid-2026. Whether that’s cheap or expensive for you is not a matter of opinion. It’s a function of three numbers you control: monthly sessions, your sample rate, and how much of the error-adjacent traffic you capture. Run the math before you commit, because the curve has a shape, and the shape has a knee.

To be clear up front: Sentry is a good product, and I say that as someone professionally suspicious of vendors. The error monitoring is mature, the replay integrates tightly with it, and if you’re already paying for Sentry errors, turning on a trickle of replays is a genuinely low-friction decision. This is an article about fit, not quality.

How Sentry session replay pricing actually works

Sentry bills replay by the captured session. Two knobs in the SDK decide what gets captured:

• replaysSessionSampleRate — the fraction of all sessions recorded, errors or not.
• replaysOnErrorSampleRate — the fraction of sessions recorded when an error occurs (buffered so you get the moments before the error too).

Both produce billable replays. The included quota on entry-level paid plans is small — think “a starter allowance,” not “your traffic” — and past it you pay per unit or pre-commit to reserved volume at a discount. I’m keeping the dollar figures qualitative deliberately; Sentry has adjusted quotas and rates more than once, and any specific number I print here will age badly. Check their pricing page; the structure is what matters for the math below.

The worked example: a SaaS with moderate traffic

Take a plausible small SaaS: 3,000 weekly active users, each averaging perhaps 15 sessions a month. Call it 45,000 sessions a month — not a big product, not a toy.

Scenario A: sample everything. 45,000 replays a month. This obliterates any included quota and puts you deep into per-unit or reserved-volume territory. At any plausible per-replay rate, this line item now rivals or exceeds the base subscription. Nobody does this on purpose; people do it by shipping replaysSessionSampleRate: 1.0 from the quickstart and finding out at invoice time.

Scenario B: the sensible Sentry config. Something like 5% session sampling plus 100% on-error. That’s 2,250 ambient replays, plus error-triggered ones — if 2% of sessions hit an error, another ~900. Roughly 3,000 replays a month. Manageable, likely a modest overage past the included allowance. This is the configuration Sentry’s own docs steer you toward, and within it the pricing is fair.

Scenario C: your product grows 3×. Same config, 135,000 sessions, ~9,500 replays. The cost scaled linearly with your success, and the only lever you have is turning the sample rate down as traffic goes up — meaning the more users you have, the smaller the fraction of their problems you can see.

That last sentence is the whole argument.

Why sampling hurts more for replay than for errors

Error events aggregate: 10,000 instances of the same exception collapse into one issue, so sampling errors costs you little diagnostic power. Replays don’t aggregate. Each one is a specific user’s specific session, and the one you need is the one attached to the support ticket in front of you.

With 5% session sampling, the answer to “can you check what this customer saw yesterday?” is no nineteen times out of twenty, unless their session happened to throw an error your SDK caught. Rage-clicks on a dead button, a form that silently refuses to submit, a checkout that “just spins” — none of these necessarily fire an error event, so on-error sampling misses them entirely. Which class of tool to lean on first is a judgment call I’ve written about in error monitoring or replay first, but the short version is: replay earns its keep precisely on the bugs that don’t throw.

Per-replay pricing therefore charges you most at exactly the moment the tool is most useful — when you want high capture rates on a growing product.

Where the flat-tier alternative crosses over

Tools priced by tier rather than by unit invert the curve. LogReplay’s hosted tiers, for instance, run Free ($0: one site, 1,000 sessions/month, 7-day retention), then $19, $79, and $249 a month as volume steps up — and within a tier, capturing more of your sessions costs nothing extra. Our 45,000-session SaaS lands in a mid tier at $79 and can record every session, including the ones that never error.

The crossover logic, without pretending to precision on Sentry’s side:

If your session volume is small or your interest in replay is strictly “show me the error in context,” Sentry’s model is fine and arguably the better deal — you’re already there for errors, and the marginal replays are nearly free at low volume. The math stops working when replay becomes your primary debugging tool rather than an error attachment, because then you want capture rates the per-unit model punishes.

The questions to ask before choosing

Not “which tool is better” — they’re different shapes. Ask:

1. What’s my honest monthly session count, and where will it be in a year?
2. When a support ticket arrives, do I need that user’s session, or is an aggregate view enough?
3. Am I comfortable telling support “we only have recordings for 5% of users”?
4. Is my error volume the thing I’m really paying for, with replay as a bolt-on?

If your answers cluster around aggregate views and error-first workflows, stay on the per-replay model and keep the sample rate low. If they cluster around “I need the specific session, most of the time” — do the multiplication with your own traffic numbers and current list prices before the invoice does it for you.