Session (RUM)
A session (RUM) is the unit of record in which Datadog RUM bundles one user's continuous interactions under a single ID. It ends when 15 minutes of inactivity pass or activity reaches 4 hours, and the next interaction starts a new session. RUM billing is also counted in this unit.
Overview
A session is the unit of record at the top of RUM data, bundling the lower-level events under one session.id. It begins at the moment the user starts browsing, and ends at whichever comes first, 15 minutes of inactivity or 4 hours of activity; interactions after that are counted as a separate session. You care about it when you want to design how the count rises and falls, because RUM billing is determined by the number of sessions. If you know the default sampling rate, the rule that excludes Synthetics-originated sessions from billing, and the structure where the Session Replay rate is applied separately, you can avoid both unexpected bills and insufficient data.
A session is a bundle of usage delimited by breaks in interaction
A session is the unit of record in which RUM groups one user's continuous interactions into one. In the official documentation's definition, a session begins at the moment the user starts browsing the web application. The RUM events collected during it are bundled under a unique session.id (as of September 2026, Source: RUM Browser Data Collected). No matter how many pages are viewed or how many times buttons are pressed, it is the same single session as long as the interaction continues without a break.
When it starts and when it ends
The end is decided by two conditions: when 15 minutes of inactivity pass, or when activity reaches 4 hours (as of September 2026, Source: RUM Browser Data Collected). Whether a session is active can be seen in the session.is_active attribute, and if there is a subsequent interaction, the next session starts with a new session.id. If you leave your seat with the tab open, the first session closes after 15 minutes, and when you come back and interact, the next session is counted. Conversely, even continuous use without a break is cut at 4 hours, so a business screen left open all day does not fit in one session.
- The user starts browsing = session start (a
session.idis issued) - While page navigations and interactions continue, they are bundled into the same session
- Ends after 15 minutes of inactivity or 4 hours of activity
- The next interaction starts a session with a new
session.id
The number of sessions one person generates in a day is determined not by dwell time but by how the interaction breaks.
What hangs under a session - retention days by type
The events that hang underneath are divided by type, and the retention days differ by type (as of September 2026, Source: RUM Browser Data Collected).
| Type | What counts as 1 event | Retention |
|---|---|---|
| Session | A bundle of one user's continuous interactions. Carries a summary of browser / device / location | 30 days |
| View | 1 event per page display. Lower-level events while on the same page are linked by view.id | 30 days |
| Action | 1 interaction such as a click. Custom actions can also be sent manually | 30 days |
| Error | 1 frontend error raised by the browser | 30 days |
| Resource | 1 load of an image / XHR / Fetch / CSS / JS | 15 days |
| Long Task | 1 operation that blocked the main thread for more than 50 ms | 15 days |
Sessions carry attributes that aggregate the counts of lower-level events, such as session.view.count and session.error.count, so you can search with a condition like "sessions that raised 3 or more errors." Because Resource and Long Task disappear first, an investigation that traces the details of loading must be finished within 15 days. For the approach to retention, see the Retention entry. Note that "event" here is a different word from the event of Event Management.
The sampling rate is two-tiered
The share to keep is decided by two rates. sessionSampleRate is the share of all sessions to track as RUM, and the default is 100. sessionReplaySampleRate is the share of that tracked portion for which Session Replay recording is also performed, applied after passing the former. The default is 0 for Browser SDK v5.0.0 and later, and 100 for earlier versions (as of September 2026, Source: Browser RUM & Session Replay Sampling). Since the latter is a percentage of the former, 50 and 50 means 25% of the total comes with a recording. Lowering only the Session Replay rate does not reduce the number of RUM sessions; if you want to reduce it, adjust sessionSampleRate. In that the narrowing happens before sending, it is the same shape as APM's Ingestion Controls.
Which sessions are counted for billing
The billing unit is also the session, and the unit price is per 1,000 sessions. On the official pricing page as of August 2026, there are two tiers: RUM Measure, which counts all traffic, and RUM Investigate, which counts only sessions after filtering (Source: Datadog Pricing). For the unit prices and the tier design, see the RUM explanation. Excluded from billing are sessions whose session.type is synthetics (as of September 2026, Source: RUM Browser Data Collected). Those generated by Synthetic Monitoring browser tests are not counted. Even if you use Session Replay in both RUM and Product Analytics, the recording is billed once (as of August 2026, Source: Datadog Pricing). This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.
When a bill comes in at 3 times the estimate
When the session count greatly exceeds the estimate, the order of suspicion is fixed. First, is one user being split into multiple sessions by the 15-minute expiry? Second, is access from bots or monitoring tools generating sessions? Third, has sessionSampleRate been left at the default of 100? Conversely, when data is insufficient, check whether the two rates have been lowered too far. Billing and data volume are balanced with these two rates.