Set Up Session Replay
If you have any questions, feedback or would like to report a bug, please open a GitHub issue with a link to a relevant replay or, if possible, a publicly accessible URL to the page you're attempting to record a replay of.
Session Replay helps you get to the root cause of an error or latency issue faster by providing you with a video-like reproduction of what was happening in the user's browser before, during, and after the issue. You can rewind and replay your application's DOM state and see key user interactions, like mouse clicks, scrolls, network requests, and console entries, in a single combined UI inspired by your browser's DevTools.
By default, our Session Replay SDK masks all DOM text content, images, and user input, giving you heightened confidence that no sensitive data will leave the browser. To learn more, see Session Replay Privacy.
For the sentry-replay integration to work, you must have the Sentry browser SDK package, or an equivalent framework SDK (for example, @sentry/react) installed. The minimum version required for the SDK is 7.27.0
. If you're on an older version of the SDK, please check the migration document.
Session Replay requires Node 12+, and browsers newer than IE11.
The Replay integration is already included with the Sentry SDK. We recommend installing the SDK through our installation wizard:
npx @sentry/wizard@latest -i remix
The wizard will prompt you to log in to Sentry. It will then automatically do the following steps for you:
- create two files in the root directory of your project,
entry.client.tsx
andentry.server.tsx
(if they don't already exist). - add the default
Sentry.init()
for the client inentry.client.tsx
and the server inentry.server.tsx
. - create
.sentryclirc
with an auth token to upload source maps (this file is automatically added to.gitignore
). - adjust your
build
script inpackage.json
to automatically upload source maps to Sentry when you build your application. - add an example page to your app to verify your Sentry setup
If you use Remix future flags, the wizard will instrument your application accordingly to support Remix v2 features.
After the wizard setup is completed, the SDK will automatically capture unhandled errors, and monitor performance. You can also manually capture errors.
If the wizard setup isn't working for you, you can set up the SDK manually.
To set up the integration, add the following to your Sentry initialization. There are several options you can pass to the integration constructor. See the configuration documentation for more details.
On your client-side Remix app, add:
import * as Sentry from "@sentry/remix";
Sentry.init({
dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
// This sets the sample rate to be 10%. You may want this to be 100% while
// in development and sample at a lower rate in production
replaysSessionSampleRate: 0.1,
// If the entire session is not sampled, use the below sample rate to sample
// sessions when an error occurs.
replaysOnErrorSampleRate: 1.0,
integrations: [
Sentry.replayIntegration({
// Additional SDK configuration goes in here, for example:
maskAllText: true,
blockAllMedia: true,
}),
],
});
With the settings above, session replays with errors are always captured. You can verify this by adding the following button to your app and pressing it:
<button
type="button"
onClick={() => {
throw new Error("Sentry Test Error");
}}
>
Break the world
</button>
Personally identifiable information (PII) and privacy are important considerations when enabling Session Replay. There are multiple ways in which Sentry helps you avoid collecting PII, including:
- Masking, which replaces the text content with something else -- the default behavior being to replace each character with a *.
- Making network request, response bodies, and headers an opt-in feature, because the best way to avoid getting PII into Sentry is by not adding URLs of endpoints that may contain PII.
While we have certain privacy considerations in place, Sentry's Session Replay allows you to set up the privacy configurations that work best for your use case. For example, if you're working on a static website that's free of PII or other types of private data, you can opt out of the default text masking and image blocking settings. To learn more about Session Replay privacy, read our docs.
Once you've added the integration, Replay will start automatically. If you don't want to start it immediately (lazy-load it), you can use addIntegration
:
Sentry.init({
// Note, Replay is NOT instantiated below:
integrations: [],
});
// Sometime later
const { replayIntegration } = await import("@sentry/remix");
Sentry.addIntegration(replayIntegration());
Canvas recording is currently in beta. Please submit an issue on GitHub if you encounter any bugs.
There is currently no PII scrubbing in canvas recordings!
If you want to record HTML canvas elements, you'll need to add an additional integration in your Sentry configuration. The canvas integration is exported from the browser SDK, so no additional package is required. Canvas recording is opt-in and will be tree-shaken from your bundle if it's not being used:
import * as Sentry from "@sentry/remix";
Sentry.init({
dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
replaysSessionSampleRate: 0.1,
replaysOnErrorSampleRate: 1.0,
integrations: [
// Keep the Replay integration as before
Sentry.replayIntegration(),
// The following is all you need to enable canvas recording with Replay
Sentry.replayCanvasIntegration(),
],
});
The canvas recording integration works by exporting the canvas as an image (at a rate of 2 frames per second). However, in order to export images from 3D and WebGL canvases, the integration needs to enable preserveDrawingBuffer
which can negatively affect canvas performance. If your canvas application is impacted by enabling preserveDrawingBuffer
, you'll need to enable manual snapshotting and call a snapshot()
method inside of your re-paint loop. There are two steps to using manual snapshotting:
Step 1. Enable manual snapshotting when initializing the ReplayCanvas
integration.
Sentry.replayCanvasIntegration({
// Enabling the following will ensure your canvas elements are not forced
// into `preserveDrawingBuffer`.
enableManualSnapshot: true,
});
Step 2 Call the the following snapshot()
method inside your application's paint loop. snapshot()
needs to be called in the same execution loop as the canvas draw commands, otherwise you may be snapshotting empty canvas buffers. This is due to how WebGL works when preserveDrawingBuffer
is false
.
function paint() {
const canvasRef = document.querySelector("#my-canvas");
Sentry.getClient().getIntegrationByName("ReplayCanvas").snapshot(canvasRef);
}
Session Replay uses a WebWorker to perform work (for example, compression) off the main UI thread so as not to degrade the performance of your application. Add the below entry to make sure that workers can be loaded:
worker-src 'self' blob:
Safari versions <= 15.4 do not support worker-src
, you will need to additionally add an entry for child-src
:
child-src 'self' blob:
If you're unable to update your CSP policy to allow inline web workers, you can also use a custom compression worker instead.
A user session starts when the Session Replay SDK is first loaded and initialized. The session will capture any pageloads, refreshes, or navigations as long as the SDK is re-initialized on the same domain, and in the same browser tab, each time. Sessions continue capturing data until 5 minutes pass without any user interactions or until a maximum of 60 minutes have elapsed. Closing the browser tab will end the session immediately, according to the rules for SessionStorage.
An interaction refers to either a mouse click or a browser navigation event.
If you prefer not to record an entire session, you can elect to capture a replay only if an error occurs. In this case, the integration will buffer up to one minute worth of events prior to the error being thrown. It will continue to record the session, following the rules above regarding session life and activity. Read the sampling section for configuration options.
Sampling allows you to control how much of your website's traffic will result in a Session Replay. There are two sample rates you can adjust to get the replays relevant to you:
replaysSessionSampleRate
- The sample rate for replays that begin recording immediately and last the entirety of the user's session.replaysOnErrorSampleRate
- 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.
Sampling begins as soon as a session starts. replaysSessionSampleRate
is evaluated first. If it's sampled, the replay recording will begin. Otherwise, replaysOnErrorSampleRate
is evaluated and if it's sampled, the integration will begin buffering the replay and will only upload it to Sentry if an error occurs. The remainder of the replay will behave similarly to a whole-session replay.
Errors that happen on the page while a replay is running will be linked to the replay, making it possible to jump between related issues and replays. However, it's possible that in some cases the error count reported on the Replays Details page won't match the actual errors that have been captured. That's because errors can be lost, and while this is uncommon, there are a few reasons why it could happen:
- The replay was rate-limited and couldn't be accepted.
- The replay was deleted by a member of your org.
- There were network errors and the replay wasn't saved.
While you're testing, we recommend that you set replaysSessionSampleRate
to 1.0
. This ensures that every user session will be sent to Sentry.
Once testing is complete, we recommend lowering this value in production. We still recommend keeping replaysOnErrorSampleRate
set to 1.0
.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").