Session Replay Alpha Launch

[jas-kas]

Session Replay by Sentry

Have you ever debugged an issue and wished you could time-travel to see all the steps a user did that lead them to the error? We certainly have, and that's why we built Session Replay for Sentry. Session Replay shows you a video-like reproduction of your user sessions so you can see what happened before, during, and after an error or latency issue occurred. Session Replay gives you deeper context on issues in your web application and takes the guesswork out of repro-ing so you can resolve issues faster.

As you playback each session, you can see every user interaction in relation to network requests, DOM events, and console messages. It’s effectively like having dev tools active for your production user sessions.

Sentry is privacy focused so protecting user data is always top of mind. That’s why we default to masking all text in our Session Replays.

Sign up for the waitlist

Session Replay is currently in alpha. You’ll likely encounter bugs - we recognize the irony. And it will only be available to a limited number of customers. Please sign up for our waitlist if you’re interested in trying it out - you’ll be contacted when it’s your turn via email. For our early adopters, we’re interested in hearing your early feedback - Where are you finding value?, Are you solving issues faster?, Did you encounter any critical defects?, How do you think replays should work in Sentry?

Want to see it in action before you sign up? Watch our demo at DEX.

Note: Session Replay is available only for web - it works alongside our JavaScript browser SDK (@sentry/browser) and web framework SDKs (@sentry/react, @sentry/angular, etc.).

We want to hear from you…

If you have any questions or feedback, please email us at session-replay@sentry.io or post down below.

[adnathanail]

I've been having a lot of fun with Replay for the last week or so, but it is being blocked by my Content Security Policy which doesn't allow worker-src: blob.

The CSP error is being thrown from this line https://github.com/getsentry/sentry-replay/blob/8e74c7edf05c041986c6739ce8bf52040b70ed93/src/eventBuffer.ts#L18

I'm not 100% sure what the worker is doing? It seems like there is a fallback in case the worker fails, but then I get a bunch of errors saying Unable to send Replay

There are 400 requests to https://sentry.io/api/1500820/envelope/?sentry_key=4d2bd6cf1a5a4291b210ff9bc4c5c9d8&sentry_version= which return {"detail":"invalid event envelope","causes":["missing newline after header or payload"]}

Is there a way that this worker can be created without requiring worker-src: blob?

[adnathanail]

@billyvg that's great thanks!

Would there be any possibility of changing how the worker is setup so that I can have the compression?

Cheers

[billyvg]

We can try to look into some alternatives, but it may not be high priority for us right now.

[chadwhitacre]

Probably worth making an issue for this, ya?

[EvHaus]

We're also having this issue. I would rather not open up blob: URLs in our CSP policy just for Sentry. Is there an alternative solution? Or some way to disable this compression setting so we avoid getting errors in our console?

[billyvg]

I've made an issue for this here getsentry/sentry-javascript#6739 -

@EvHaus You could pass in the useCompression: false option when initializing the replay SDK.

[angelajiang13]

It's been ~2 months since Sentry launched Session Replay in alpha. Since then, our internal teams have been busy collecting customer feedback, making improvements to the product, and listening to our customers on what value they derive from Sentry's Session Replay.

In the spirit of building in public, I’d like to share a few insights around what we have been hearing from users during this alpha & closed beta period.

Key differentiators of Sentry’s Session Replay

• Ability to sample sessions that are tied to a specific error so that you only capture the data that you need
• Promotes strong privacy settings out-of-the-box (more aggressive than other Session Replay tools)

Key value of Sentry's Session Replay

• Visualize and inspect the steps a user took before an issue was triggered
• Deep context into sessions including DOM events, console logs, and network details to help developers debug faster
• Frictionless setup with simple installment of the SDK
• Deep integration with errors and transactions so devs can get to the root cause of issues faster

Surfaced use cases

1. Help developers debug/root cause issues faster
2. Visually see where users are getting stuck or confused by reviewing unusually long sessions
3. Understand customer user journeys to improve conversion and retention

We want to know which frontend errors you would like to solve with a Session Replay❗️Let us know 👇

If you are interested in becoming an early adopter of Sentry's Session Replay, sign up for the waitlist or message us at session-replay@sentry.io.

[jyunhanlin]

Hi Sentry team,

After checking the source code, it seems need to set up the sessionSampleRate or errorSampleRate (one of them needs to be larger than 0) so that the replay will start recording.

We want to send the recording replay to the sentry when the user clicks the bug report button.
Is it possible to start recording without setting the sessionSampleRate or errorSampleRate but we still can send the replay recording programmability by the replay.flush() ?

[billyvg]

Currently there is no way for you to control sending the replay, but I've created a ticket for your feature request: getsentry/sentry-javascript#6420

Can you give an example of what you're trying to accomplish when multiple Sentry instances? The Replay SDK has not been tested with micro-frontends and should only be attached to the DOM once.

[jyunhanlin]

Can you give an example of what you're trying to accomplish when multiple Sentry instances? The Replay SDK has not been tested with micro-frontends and should only be attached to the DOM once.

We use two sentry instances.
The main one is to capture the error as the sentry always did.
The second one is to collect the user report with some extra data when the user clicks the report button, and we will send the replay recording simultaneously.
While the replay library uses the main instance so that the replay session might link to the issues from the main one instead of the user report of the second instance.
We want the replay session could link to the user report of the second instance.

[billyvg]

Is there a reason why you can't do both with one instance?

[jyunhanlin]

We want to ensure the user report can be sent.
If we use the same sentry, we might exceed the quota, so the user report can't be sent.
And also, It's easier to find the user report.

[billyvg]

Ah I see. Supporting multiple Sentry instances isn't something we are planning to support in the near term, though you may be able to get your use case to work when #6420 is added.

[TsubasaBE]

A quick question...
Is session replay available on self-hosted? I can enable it in server.py, but replays aren't showing up in the ui, although I see the JS SDK emit events without errors.

[chadwhitacre]

Not yet. We've got a ticket at getsentry/self-hosted#1873 if you want to follow along. Aiming for next quarter. 🤞

[TsubasaBE]

Thank you very much for the quick reply. I'll follow getsentry/self-hosted#1873.