Sentry session recording capabilities

[maciej-gurban]

Problem Statement

Hi! We’re active users of Sentry, particularly its session replay capabilities. We currently track 100% of our traffic to (1) understand how users interact with the product, (2) observe and reproduce customer issues, and (3) give engineers visibility into the UI when errors or performance issues occur. At the same time, we’re also using LogRocket - also at 100% of traffic. Our original plan was to consolidate everything into Sentry, but we’ve found that some critical features are missing.

1. Session replays do not capture the full user journey

Understanding a user’s workflow requires visibility across all tabs and windows they open. For example: did the user open a new tab, take an action there, and return to the original? Or did they branch into multiple new tabs in sequence?

In Sentry, every new window starts a separate session recording. There’s no way to link them into a cohesive flow. This leaves us without the full picture of a user’s journey and increases costs, since each tab creates a new session.

To put this in perspective: out of 1.4M recordings, about 600k are under 1 minute - often just users opening a document in a new tab, glancing at it, and closing it. In LogRocket, these same events are stitched together as part of a single user session. There, we’re logging about 800k unique sessions rather than 1.4M fragments.

2. Limited control over what gets captured

Session replay impacts performance, so we can only realistically afford to use a single tool for screen capture. If that tool is Sentry, it needs more flexibility in how recording is controlled.

Currently, capture decisions require code changes and production releases. Instead, we’d like UI-level configuration so Product Managers can adjust capture rules without engineering involvement. Examples:

• Capture all sessions when releasing a new feature
• Capture a small percentage of traffic for established features
• Capture sessions only on specific pages or with specific interactions
• Capture sessions only when errors occur

LogRocket’s conditional recording illustrates the type of functionality we’re looking for.

3. Missing sessions without explanation

We’ve also observed discrepancies where a session appears in LogRocket but not in Sentry, even though we were well under our monthly quota. There’s currently no visibility into why a given session was dropped, leaving it a black box for us - we cannot find Sentry traces either.

These numbers look somewhat concerning but it's unclear what can I do about so many invalid sessions

Solution Brainstorm

TL; DR: We need to stitch new tab/window opens into a single session screen recording, better control over what gets captured via UI, and true 100% capture of sessions.

Product Area

Replays

[linear]

ENG-5527 Sentry session recording capabilities

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[getsantry]

Routing to @getsentry/product-owners-replays for triage ⏲️

[cmanallen]

Hi @maciej-gurban. Thanks for reaching out!

Understanding a user’s workflow requires visibility across all tabs and windows they open. For example: did the user open a new tab, take an action there, and return to the original? Or did they branch into multiple new tabs in sequence?

This is a feature we want to offer. We may be starting work on it as early as next week but I'm not certain. Sometime in the next one to two months we should have a concept of tabbed sessions.

Currently, capture decisions require code changes and production releases. Instead, we’d like UI-level configuration so Product Managers can adjust capture rules without engineering involvement.

This is something we likely won't offer in the near-term (~1 year range).

However, (disclaimer: I have not done this) you could use another product to control replay recording. You could use statsig, unleash.io, Firebase remote config, launchdarkly, flagsmith, or growthbook. Your feature flags won't be consolidated into a single observability product but you will have finer grained control over what is and is not recorded.

We’ve also observed discrepancies where a session appears in LogRocket but not in Sentry, even though we were well under our monthly quota. There’s currently no visibility into why a given session was dropped, leaving it a black box for us - we cannot find Sentry traces either.

Take a look at this page. It will show you how to configure inbound filters. Though, in your case you'll use this knowledge to disable your filters. That should give you true 100% sampling. If there's still a discrepancy between Sentry and LogRocket we'll do a deeper dive and figure out whats wrong.