User sessions in web frontends

  • Latest Dynatrace
  • Explanation
  • Published Mar 03, 2026

A user session summarizes user events for a single end user within a limited timeframe, recording timing information and aggregating key counts and errors for fast analysis. This page describes how user sessions work for web frontends in the New RUM Experience and how they relate to user sessions in RUM Classic.

User session lifecycle

At this point, user sessions in the New RUM Experience are still created based on RUM Classic user sessions. However, in contrast to RUM Classic, which has a user action limit of 200 per user session, the New RUM Experience does not impose any limits on the number of actions or events per user session.

Session start

A user session can start in two ways:

  • When the user performs the first user action in RUM Classic, for example, a load action or an XHR action.
  • When the previous user session has ended; see below.

Session end

A user session ends in one of the following ways:

  • After 30 minutes of browser inactivity.
  • When the user closes their browser.
  • When the session duration reaches 6 hours.
  • When the session is ended via the RUM JavaScript API by calling dtrum.endSession().

Session and instance identifiers

The RUM JavaScript stores the following identifiers in RUM Cookies and adds them to each captured user event:

  • dt.rum.session.id identifies the session the event belongs to.
  • dt.rum.instance.id identifies the user's browser. Unless Use persistent cookies for user tracking is disabled, it's stored in a persistent cookie and therefore suitable for identifying returning users.

Aggregation of user events into sessions

The dt.rum.session.id field allows Dynatrace to aggregate user events into user sessions. One session may traverse multiple frontends. For a session to be stored in Grail, it must contain at least one navigation event. For example, sessions that consist only of request events are not persisted.

Comparison with RUM classic user sessions

The image below shows how user sessions are captured in scenarios where RUM Classic and the New RUM Experience collect fully overlapping data.

Diagram - User sessions in the New RUM Experience

The New RUM Experience no longer splits user sessions after 200 user actions or events. In RUM Classic, a session with 600 user actions would be divided into three separate sessions during session aggregation, whereas the New RUM Experience represents this as a single continuous session. This difference in session handling can lead to variations in user session counts.

Diagram - User sessions in the New RUM Experience have no event limit

Limitations

The reliance on RUM Classic sessions—combined with the fact that the New RUM Experience captures a more comprehensive set of data—can lead to limitations in certain scenarios.

  • The New RUM Experience captures request events—for example, due to polling in a web page—which RUM Classic does not consider activity that should extend a session. As a result, even though the New RUM Experience reports continuous activity in the browser, the session may be split.

  • RUM Classic automatically starts a new session after the previous one times out. This can then lead to scenarios where sessions in the New RUM Experience begin with requests—or other events specific to the New RUM Experience—and only later include navigation or user action events.

In scenarios like these, the user session counts in the New RUM Experience and in RUM Classic will differ.

Diagram - Limitations of user sessions in the New RUM Experience

Related tags
Digital Experience