How a Session Replay Sampling Rate Works in Sentry, PostHog and Others

What is a session replay sampling rate?

A session replay sampling rate is the share of user sessions that a replay tool records, usually written as a fraction between 0 and 1 or a percentage between 0 and 100. At a rate of 0.1, roughly one session in ten is recorded in full and the other nine are not. Sentry's documentation puts it in one line: "Sampling controls how much traffic results in a Session Replay."

The rate is decided once, when the session starts, so a sampled-out visitor stays sampled out for the whole visit. That matters because a session replay only makes sense as a whole: a recording missing its first full DOM snapshot cannot be played back.

Vendors disagree on the unit, the default and where you set it. The sections below quote each vendor's own docs.

How is session-level sampling different from event-level sampling?

Session-level sampling decides whether a session is recorded at all. Event-level sampling records the session but drops or throttles some events inside it. The first controls how many replays you store. The second controls how heavy each replay is.

The open-source recorder rrweb shows event-level sampling clearly. Its sampling option takes keys such as mousemove, scroll, media and input, and its storage recipe sets scroll: 150 with the comment "do not emit twice in 150ms" and input: 'last' so only the final value of a typed sequence is kept. Every session is still recorded, just with fewer events.

Neither is the same as the sampling an analytics report applies when it estimates totals from a subset of rows. That kind is covered in when data sampling starts in a report.

How does Sentry use replaysSessionSampleRate and replaysOnErrorSampleRate?

Sentry uses two rates, set in Sentry.init(). Its configuration reference defines them this way:

• replaysSessionSampleRate, type number, default 0: "The sample rate for replays that begin recording immediately and last the entirety of the user's session. 1.0 collects all replays, and 0 collects none."
• replaysOnErrorSampleRate, type number, default 0: "The sample rate for replays that are recorded when an error happens. This type of replay will record up to a minute of events prior to the error and continue recording until the session ends."

Sentry's setup page explains the order. replaysSessionSampleRate is checked first. If the session is sampled, "Full session recording starts and is sent to Sentry in real-time." If it is not, the recording is "buffered in memory only (last 60 seconds kept)". When an error occurs in an unsampled session, replaysOnErrorSampleRate is checked, and a hit sends the "Buffered 60 seconds + rest of session". A miss discards the buffer and nothing is sent.

Sentry publishes two different defaults for the same options. The configuration reference lists 0 for both, so an SDK install that sets neither records nothing. The Loader Script snippet on the setup page says it "will initialize Replay with the default config: replaysSessionSampleRate: 0.1, replaysOnErrorSampleRate: 1". Which default you get depends on how you installed Sentry, and it is worth checking which one your project is running.

Sentry is also the one vendor here that publishes a table of recommended rates, in a table titled "Recommended Production Sample Rates":

Its advice on the error rate is blunt: "Keep replaysOnErrorSampleRate at 1.0 - error sessions provide the most debugging value." For testing it recommends replaysSessionSampleRate: 1.0.

How does PostHog sample session recordings?

PostHog sets its sampling rate in the replay ingestion settings, not in SDK code. Each "trigger group" has its own conditions (URL triggers, event triggers, a feature flag) plus "its own sample rate, minimum duration, and match type". A session is recorded if it matches any group.

PostHog's sampling is deterministic. Its docs say: "When a new session starts, PostHog converts the session ID into a number between 0 and 1 using a hash function. This number is then compared to your configured sample rate (for example, 0.1 for 10% or 0.2 for 20%)." The same session ID always gets the same answer, "even across page refreshes". The docs also say what you give up: "You can't choose which sessions are sampled."

The rate applies after a group's conditions, not alongside them. PostHog's example is "a group with an exception event trigger and a 20% sample rate records 20% of the sessions that threw an exception", not 20% of all sessions plus every exception. If you delete your last trigger group, PostHog replaces it with a default "Record all sessions" group at 100% sampling. Its published recommendation runs the opposite way to Sentry's table: "Our recommendation is to start with capturing 100% of sessions and decrease it as needed."

How does LogRocket handle sampling?

LogRocket sets sampling rates inside Conditional Recording, which its docs label "Available as a separate add on for Pro and Enterprise customers". You create a recording condition, such as a click on a checkout button or a network error, and "set the sampling rate" for it. The docs give "record 20% of users who visit our checkout page" as an example. Multiple conditions "will be considered separately, not cumulatively, so a session needs to meet only one condition in order to be recorded."

Because a condition can fire midway through a visit, LogRocket keeps a lookback: "All recordings record up to 10MB of activity prior to the recording condition being met." That is a byte limit, not a time limit, so the lookback length varies from session to session.

Without the add-on, the controls on LogRocket's Recording Settings page are limits and filters, not rates: pause recording, a monthly or daily session limit, and blocks by location, IP address, app version or user agent. LogRocket's public docs describe no SDK parameter for a sampling rate and publish no recommended rate.

Does Microsoft Clarity sample session recordings?

Clarity's FAQ says it does not, then lists a cap. Under "Why should I use Clarity?" it promises "No sampling (that is, tracking only a portion of your site's traffic)" and "there are no traffic limits on these sites." Further down, the same page answers "How many sessions can Clarity record?" with "Clarity records up to 100,000 sessions per project per day." A third answer adds: "Clarity tracks all sessions, but recordings might not be available for all sessions."

Read together, Clarity tracks every session but caps recordings, and it does not document how it chooses which sessions to record past the cap. Clarity exposes no sampling rate setting.

How does Datadog's sessionReplaySampleRate work?

Datadog nests two percentages. sessionSampleRate "controls the percentage of overall sessions being tracked" and defaults to 100. sessionReplaySampleRate "is applied after the overall sample rate, and controls the percentage of sessions tracked as Browser RUM & Session Replay." Both take values from 0 to 100, not 0 to 1.

Datadog's sampling guide works an example: "If you set sessionSampleRate to 60 and sessionReplaySampleRate to 50, 40% of sessions are dropped, 30% of sessions are collected as Browser RUM, and 30% of sessions are collected as Browser RUM & Session Replay." The default moved in a major version: from Browser SDK v5.0.0, "the sessionReplaySampleRate initialization parameter default value is 0. Previous versions of the SDK use 100."

How do vendors compare on session replay sampling rates?

What session replay sampling rate should you choose?

Start from the rarest problem you need to see, not from the budget. The arithmetic is simple: if a bug hits one session in 400 and you record 10% of sessions, you capture it about once every 4,000 sessions. Lower the rate and the wait grows in proportion. Sentry's error rate exists because a flat rate works against rare events, and PostHog's trigger groups and LogRocket's conditions let you keep 100% on checkout or signup while sampling everything else.

Two checks before you ship a rate. First, confirm the default your install actually uses, since Sentry and Datadog both publish a 0 that means "record nothing". Second, count both sides: sessions times rate gives recordings, which is what a per-recording plan bills and what your privacy review has to cover. Sampling cuts exposure as well as cost, which our session replay tools comparison looks at vendor by vendor.

Flowsery's install instructions for its recording script state: "Recording and AI sampling are both 100% unless explicitly changed." Every session is recorded and reviewed by the AI in Flowsery's AI session replay unless you lower it.

Frequently asked questions

What does replaysSessionSampleRate 0.1 mean in Sentry?

It means Sentry records about 10% of sessions in full from the moment they start. Sentry's docs describe 1.0 as collecting all replays and 0 as collecting none.

What is the default session replay sampling rate in Sentry?

The SDK configuration reference lists 0 for both replaysSessionSampleRate and replaysOnErrorSampleRate. Sentry's Loader Script uses 0.1 and 1 as its default config instead.

Does replaysOnErrorSampleRate record what happened before the error?

Yes. Sentry buffers the last 60 seconds in memory for unsampled sessions, and a sampled error sends that buffer plus the rest of the session.

Can I choose which sessions PostHog samples?

No. PostHog hashes the session ID into a number between 0 and 1 and records the session if that number is below your rate. Its docs state that "You can't choose which sessions are sampled."

Is Datadog's sessionReplaySampleRate a percentage of all sessions?

No. It is a percentage of the sessions already kept by sessionSampleRate. At 60 and 50, Datadog's own example collects replays for 30% of all sessions.

Does Microsoft Clarity record every session?

Clarity's FAQ says it does no sampling, but it also says Clarity records up to 100,000 sessions per project per day and that recordings "might not be available for all sessions."

What happens to sessions Sentry doesn't sample?

Sentry buffers the session in memory instead of dropping it entirely. The setup page describes this buffer as the last 60 seconds kept, so it rolls forward for the whole visit. When an error occurs, replaysOnErrorSampleRate is checked: a hit sends the buffer plus the rest of the session, and a miss discards the buffer. A session with no error sends nothing to Sentry.

What sampling rate does PostHog recommend to start with?

PostHog's documentation recommends starting with capturing 100% of sessions and decreasing the rate only as needed. That runs opposite to Sentry's table, which recommends dropping to 1% at high traffic volumes. It also matches the fallback PostHog creates when you delete your last trigger group: a "Record all sessions" group at 100% sampling with no conditions.

Does LogRocket's conditional sampling come with every plan?

LogRocket sells Conditional Recording, the feature that sets a sampling rate per condition, as a separate add-on for Pro and Enterprise customers. Plans without it get limits and filters instead: pause recording, a monthly or daily session cap, and blocks by location, IP address, app version or user agent. None of those act as a sampling rate.

How does rrweb reduce data within a recorded session?

rrweb trims the data inside each recording through its sampling option, not by skipping whole sessions. Its storage recipe caps scroll events at one every 150 milliseconds and keeps only the last value of a typed input sequence. Every session still gets recorded; only the volume of events inside it shrinks.