Watch exactly what
your users experienced.

Input values are masked before the recording leaves the browser on applications you create, and password fields are masked whether or not that setting is on. Page text is a separate setting and it is off by default, so visible text your page renders (names, addresses, order contents, message bodies) is recorded unless you turn page-text masking on for the application or mark the element. Content inside a cross-origin iframe is never recorded at all, which is why a hosted payment field cannot be captured. Applications created before this default was corrected keep the setting they were stored with, so check the toggle in RUM settings for any application you set up earlier.

Add a class to the element. rr-mask masks the text inside it, rr-block stops the element being recorded at all, and rr-ignore stops input events on it being recorded. These are the recorder's own class names and Site Qwality does not override them, so they work as documented upstream. There is no data-sq-mask or data-sq-unmask attribute; earlier versions of this page said there was, and that was wrong.

The core RUM script is 5.7 kB gzipped over the wire and loads asynchronously. The recorder itself is a separate 22 kB gzipped chunk that is only fetched when a session actually matches a capture filter, so a visitor who is not being recorded never downloads it. Mutations are batched and flushed on a timer rather than per event.

Open the error in Error Tracking. The detail view lists the sessions the error occurred in, and each row has a Watch Replay link that opens that session's recording. The recording plays from the point the session was selected for capture; there is no pre-error buffer.

You can filter the session list by browser, operating system, whether the session contained an error, whether it has a replay, and whether it shows frustration signals, and search by the user id or email address you passed to setUser. Filtering by URL, device class, session duration or custom attribute is not available today.

30 days, on every plan including the free tier. The window is not configurable in either direction: paid plans do not extend it, and unlike the two other real user monitoring windows it cannot be shortened either. A request that tries to set a shorter replay window is refused with an error naming the reason rather than quietly accepted and ignored. The reason is that the index row we keep in the database only points at the stored recording, and the recordings are expired by a separate storage rule that applies to all of them equally and cannot follow a per-application setting; honouring a shorter window would delete the pointer while leaving the recording in place. What a plan changes is how many sessions you can record, not how long they are kept.