Sessions
What a session records, how crash-free session rate is calculated, and how session context reaches an issue.
A session is the record of one user's continuous interaction with your application: the pages they visited, the features they used, the requests they made, how long those took, and every error they encountered — in one ordered timeline.
Why one timeline
Reproducing a bug usually means reconstructing what the user was doing. When sessions, errors and performance live in separate systems, that reconstruction is manual and approximate: you match timestamps by hand and hope the clocks agree.
In one timeline it is just reading. That is the whole argument for collecting the three signals through a single SDK rather than three.
What ends a session
A session ends when the user stops interacting for long enough that the next interaction is a new visit, or when the application is closed. By default that is 30 minutes without activity. The idle window is configurable in the dashboard rather than in the SDK, so changing it does not require a redeploy.
Sessions are not user accounts and not visits to a single page. One user can have many sessions; one session can span many pages.
Crash-free sessions
Session data gives reliability a denominator.
1,291 errors
means little on its own. It could be one broken loop or a thousand broken users.
98.6 percent of sessions completed without an error
is a number you can hold a team to, track across releases, and compare between environments. It is also the reliability number most likely to survive a change in traffic volume, because it is a rate rather than a count.
Crash-free session rate is reported per release, which is what makes a bad deployment visible. A crash, for this rate, is a fatal event or an unhandled error.
Sessions are event timelines, not recordings: there is no screen recording and no replay.
Session context on an issue
Every issue shows the sessions it affected, so an exception carries the behaviour that led to it rather than only the stack trace that ended it. The breadcrumb trail on an event and the session it belongs to are two views of the same data at different resolutions.
Identity
Sessions are tied together by the user identifier you set. Choose one that is meaningful to you and no more identifying than it needs to be — an internal account id is usually a better choice than an email address. Without an identifier, sessions still work; they just cannot be linked across devices.
See Data and privacy for what is stored and how to scrub it.
Related
Last updated October 20, 2026