Set Up Session Replay

Session Replay helps you get to the root cause of an error or latency issue faster by providing you with a reproduction of what was happening in the user's device before, during, and after the issue. You can rewind and replay your application's state and see key user interactions, like taps, swipes, network requests, and console entries, in a single UI.

By default, our Session Replay SDK masks all text content, images, and user input, giving you heightened confidence that no sensitive data will leave the device. To learn more, see product docs.

Pre-requisites

Make sure your Sentry React Native SDK version is at least 5.26.0.

Install

If you already have the SDK installed, you can update it to the latest version with:

npm install @sentry/react-native --save

Set Up

To set up the integration, add the following to your Sentry initialization.

import * as Sentry from "@sentry/react-native";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  _experiments: {
    replaysSessionSampleRate: 1.0,
    replaysOnErrorSampleRate: 1.0,
  },
  integrations: [Sentry.mobileReplayIntegration()],
});

Verify

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.

Sampling

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:

1. replaysSessionSampleRate - The sample rate for replays that begin recording immediately and last the entirety of the user's session.
2. 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.

Privacy

The SDK is recording and aggressively masking all text, images, and webviews by default. If your app has any sensitive data, you should only turn the default masking off after explicitly masking out any sensitive data, using the APIs described below. However, if you're working on a mobile app that doesn't contain any PII or private data, you can opt out of the default text and image-masking settings. To learn more about Session Replay privacy, read our docs.

To disable redaction altogether (not to be used on applications with sensitive data):

Sentry.mobileReplayIntegration({
  maskAllText: false,
  maskAllImages: false,
  maskAllVectors: false,
}),

React Component Names

Sentry helps you capture your React components and unlock additional insights in your application. You can set it up to use React component names.

So instead of looking at this:

View > Touchable > View > Text

You can also see exactly which React component was used, like:

MyCard (View, MyCard.ts) > MyButton (Touchable, MyCard.ts) > View > Text

To add React Component Names use annotateReactComponents in metro.config.js.

const { getDefaultConfig } = require("@react-native/metro-config");
const { withSentryConfig } = require("@sentry/react-native/metro");
module.exports = withSentryConfig(getDefaultConfig(__dirname), {
  annotateReactComponents: true,
});

Error Linking

Errors that happen 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.