Increase replay buffering from 60 seconds to 5 minutes to allow for easier debugging and match requestly

[kkmuffme]

Unfortunately, the 60 seconds buffering in Sentry often is too short for effective debugging errors. In many cases the origin of the error, especially with B2B applications, happens because something the user did 2-3 minutes ago.

Other tools like https://requestly.com/products/session-book/ have a 5 minute look back (which is excessive, since we 3 minutes were enough in all our test cases).

Increasing the replay buffering value would tremendously improve the usefulness of this feature.

[getsantry[bot]]

Assigning to @getsentry/support for routing ⏲️

[getsantry[bot]]

Routing to @getsentry/product-owners-replays for triage ⏲️

[bruno-garcia]

The problem is keeping 5 minutes worth of data on the client. Since that's stored on the users device, in case the replay is sampled, 5 minutes worth of data could be a lot of data, potentially slowing things down.

You could have a higher sample rate for sessions, so you'll record the full replay since the start of the users journey. Would that help?

[kkmuffme]

I totally agree that 5 minutes is excessive but increasing it to 2 maybe 2.5 minutes would be a major increase in usability, while keeping the amount of data on the client low.

You could have a higher sample rate for sessions, so you'll record the full replay since the start of the users journey. Would that help?

We tried that, however this was a lose-lose thing: we ended up with tons of recordings that were useless (since no error occurred) and those sessions where an error occurred of course weren't sampled...

[bruno-garcia]

while keeping the amount of data on the client low.

this is the challenge I believe. But if we could keep it at a max size in bytes, that could work. Like buffer length is 30 seconds, or X bytes, that could be minutes of recording if the site is small enough.

@billyvg thoughts?

[c298lee]

We can add an option to increase the buffer size to up to 2 minutes, with a warning that this may cause slow downs or crashes

[kkmuffme]

How about <= 2 minutes OR ( > 2 minutes && total size < X bytes )? (where the 2nd condition should probably be applied by default, that it will allow longer recordings if it's below a certain threshold of data, to allow recordings where nothing/very little/lots of basically idle) happens

[bruno-garcia]

How about <= 2 minutes OR ( > 2 minutes && total size < X bytes )? (where the 2nd condition should probably be applied by default, that it will allow longer recordings if it's below a certain threshold of data, to allow recordings where nothing/very little/lots of basically idle) happens

Agree that'd be ideal. Unfortunately it's not a very straightforward change. If you'd keen to contribute it to the SDK we'd be glad to review and get that in, but I'm afraid it might take a while before one of us can get that done