diff --git a/docs/platforms/android/session-replay/index.mdx b/docs/platforms/android/session-replay/index.mdx index 959394fdb63d2..f8c4f55b243f1 100644 --- a/docs/platforms/android/session-replay/index.mdx +++ b/docs/platforms/android/session-replay/index.mdx @@ -112,7 +112,7 @@ options.experimental.sessionReplay.redactAllImages = false ## Error Linking -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: +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. diff --git a/docs/platforms/apple/guides/ios/session-replay/index.mdx b/docs/platforms/apple/guides/ios/session-replay/index.mdx index 9f4289ad81501..a82572249a761 100644 --- a/docs/platforms/apple/guides/ios/session-replay/index.mdx +++ b/docs/platforms/apple/guides/ios/session-replay/index.mdx @@ -92,7 +92,7 @@ options.experimental.sessionReplay.redactAllImages = false ## Error Linking -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: +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. diff --git a/docs/platforms/flutter/session-replay/index.mdx b/docs/platforms/flutter/session-replay/index.mdx new file mode 100644 index 0000000000000..d350fd4a8f609 --- /dev/null +++ b/docs/platforms/flutter/session-replay/index.mdx @@ -0,0 +1,101 @@ +--- +title: Set Up Session Replay +sidebar_order: 5500 +notSupported: +description: "Learn how to enable the Mobile Session Replay Beta in your app." +--- + + + +Mobile support for Session Replay is in Beta. Features available in Beta are still work-in-progress and may have bugs. We recognize the irony. + +If you have any questions, feedback or would like to report a bug, please open a [GitHub issue](https://github.com/getsentry/sentry-dart/issues/new?template=BUG_REPORT.yml) with a link to a relevant replay in Sentry if possible. + + + +[Session Replay](/product/explore/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](/product/explore/session-replay/). + +## Pre-requisites + +Make sure your Sentry Flutter SDK version is at least 8.9.0, which is required for Session Replay. +You can update your `pubspec.yaml` to the matching version: + +```yaml +dependencies: + sentry_flutter: ^8.9.0 +``` + +## Setup + +To set up the integration, add the following to your Sentry initialization: + +```dart +await SentryFlutter.init( + (options) { + ... + options.experimental.replay.sessionSampleRate = 1.0; + options.experimental.replay.onErrorSampleRate = 1.0; + }, + appRunner: () => runApp(MyApp()), +); +``` + +## Verify + +While you're testing, we recommend that you set 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 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. - The sample rate for + replays that begin recording immediately and last the entirety of a user's session. +2. - 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 starts as soon as a session begins. The is then evaluated. If the session is sampled, replay recording will start immediately. If not, will be evaluated. If the session is sampled at this point, the replay will be buffered and will only be uploaded to Sentry if an error occurs. + +## Privacy + +The SDK is recording and aggressively redacting (masking) all text and images, according to the configuration in `options.experimental.replay`. +You can tune this and add custom masking rules to fit your needs. For example, you can explicitly mask or unmask widgets by type, +or you can even have a callback to decide whether a specific widget instance should be masked: + +```dart + options.experimental.replay.mask(); + options.experimental.replay.unmask(); + options.experimental.replay.maskCallback( + (Element element, Text widget) => + (widget.data?.contains('secret') ?? false) + ? SentryMaskingDecision.mask + : SentryMaskingDecision.continueProcessing); +``` + +You can find more details in the documentation for each method. + + + +If you find that data isn't being redacted with the default settings, please let us know by creating a [GitHub issue](https://github.com/getsentry/sentry-dart/issues/new?template=BUG_REPORT.yml). + + + +To disable redaction altogether (not to be used on applications with sensitive data): + +```dart + options.experimental.replay.maskAllText = false; + options.experimental.replay.maskAllImages = false; +``` + +## 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. diff --git a/docs/platforms/react-native/session-replay/index.mdx b/docs/platforms/react-native/session-replay/index.mdx index 37efcabcb46b0..6d88fd78d7b37 100644 --- a/docs/platforms/react-native/session-replay/index.mdx +++ b/docs/platforms/react-native/session-replay/index.mdx @@ -128,7 +128,7 @@ const config = getSentryExpoConfig(__dirname, { ## Error Linking -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: +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. diff --git a/docs/product/explore/session-replay/mobile/index.mdx b/docs/product/explore/session-replay/mobile/index.mdx index fb79e16050eb2..1ac32377b4cd1 100644 --- a/docs/product/explore/session-replay/mobile/index.mdx +++ b/docs/product/explore/session-replay/mobile/index.mdx @@ -56,13 +56,14 @@ These breadcrumbs are synced with the replay player and will auto-scroll as the ## SDKs Supported -Session Replay for mobile is currently available for Android, iOS, and React Native SDKs. Support for [Flutter](/platforms/flutter/) is being tracked on this [GitHub issue](https://github.com/getsentry/sentry-dart/issues/1193). +Session Replay for mobile is currently available for Android and iOS on both native SDKs, as well as for React Native and Flutter. -We recommend updating to the latest, but the miminum versions supported are: +We recommend updating to the latest version, but the minimum versions supported are: - [iOS](/platforms/apple/guides/ios/session-replay/), [8.31.1](https://github.com/getsentry/sentry-cocoa/releases) - [Android](/platforms/android/session-replay/), [7.12.0](https://github.com/getsentry/sentry-java/releases) - [React Native](/platforms/react-native/session-replay/), [5.26.0](https://github.com/getsentry/sentry-react-native/releases) +- [Flutter](/platforms/flutter/session-replay/), [8.9.0](https://github.com/getsentry/sentry-dart/releases) ## Frequently Asked Questions @@ -77,7 +78,7 @@ Additionally, we offer a self-serve deletion capability of individual replays in For most mobile applications, the performance overhead of our client SDK will be imperceptible to end-users. In our own testing, the overhead was not noticeable by end-users. However, this testing was not exhaustive and you may discover the recording overhead may negatively impact your mobile application performance depending on your application complexity. To reduce the performance overhead, we only take screenshots when something changes on the screen. Our default frame rate is 1 frame (16ms) per second of the main thread time. -If you experience any performance degradations after installing Session Replay, please open an issue on GitHub for your respective SDK: [Android](https://github.com/getsentry/sentry-java/issues/new/choose), [iOS](https://github.com/getsentry/sentry-cocoa/issues/new/choose) and [React Native](https://github.com/getsentry/sentry-react-native/issues/new/choose). +If you experience any performance degradations after installing Session Replay, please open an issue on GitHub for your respective SDK: [Android](https://github.com/getsentry/sentry-java/issues/new/choose), [iOS](https://github.com/getsentry/sentry-cocoa/issues/new/choose), [React Native](https://github.com/getsentry/sentry-react-native/issues/new/choose), and [Flutter](https://github.com/getsentry/sentry-dart/issues/new/choose). **How much does it cost to use Session Replay for mobile?**