Explanation
Why the waste happens and who it affects.
Under RUM without Limits, every session sent by the SDK is billed at the low RUM Measure rate, while each session kept by a retention filter is billed again at the much higher RUM Investigate rate, and a retained session that includes a replay is also billed for Session Replay. Teams that create broad custom retention filters at or near 100%, or keep sessionReplaySampleRate high after moving sessionSampleRate to 100%, end up retaining and replaying most of their traffic.
On accounts still billed per session sent by the SDK, the same waste shows up as a high sessionSampleRate on high-traffic applications. In both cases the sessions needed for troubleshooting are a small share of traffic: sessions with errors, crashes, slow views or key user flows. Out-of-the-box RUM metrics such as Core Web Vitals are computed before retention filters, so retaining fewer sessions does not reduce metric accuracy. Because session counts scale directly with users, the effect is largest on busy consumer web and mobile applications.
Billing model
The pricing dimensions that drive this cost.
On Datadog's public pricing page, the RUM without Limits SKUs are billed per 1,000 sessions per month.
- RUM Measure
- Every session the SDK sends to Datadog ($0.15 per 1,000 sessions billed annually, $0.22 on demand)
- RUM Investigate
- Each session retained by a retention filter ($3 per 1,000 sessions billed annually, $4.50 on demand)
- Session Replay
- Each retained session that includes a replay ($2.50 per 1,000 sessions billed annually, $3.60 on demand)
- Permanent retention filters
- Predefined filters for forced replays, RUM-APM flat sampling and Synthetics sessions; the latter two are not subject to RUM billing
How to detect
5 checks to find it in your estate.
- Chart datadog.estimated_usage.rum.ingested_sessions against datadog.estimated_usage.rum.indexed_sessions per application: a retained share close to the ingested share means retention filters keep most traffic
- In each application's Retention Filters settings, review custom retention filters for broad queries (for example all views or all sessions) with high retention rates, and use Generate Estimate to see their expected volume
- Review SDK initialization for sessionReplaySampleRate left at its pre-migration value after sessionSampleRate was raised to 100% for RUM without Limits, which multiplies the number of replays
- On accounts not using RUM without Limits, find high-traffic applications with sessionSampleRate at or near 100 in the Browser or mobile SDK configuration
- Check whether a daily retention quota is configured per application, and track rum.measure.usage.quota_blocked_sessions where it is
How to fix
5 ways to remove the waste.
- Rebuild custom retention filters around the sessions that matter, such as sessions with errors or crashes, slow views and critical flows like checkout, at 100%, and keep a low-rate general sample instead of a broad high-rate filter; order matters because an event is evaluated only by the first matching filter
- Lower sessionReplaySampleRate so replays are only recorded for the share of sessions that need them; when sessionSampleRate is raised from 20 to 100, Datadog's example reduces sessionReplaySampleRate from 10 to 2 to keep the same number of replays
- Set a daily retention quota per application with Stop retention or Slow down retention (keeps 10% of sessions that would be retained) to cap spikes from traffic surges or misconfigured filters
- On accounts billed per session sent, lower sessionSampleRate on high-traffic applications; changing it requires a redeploy unless the SDK is added by server-side injection or set through a feature flag or remote configuration
- Tradeoff: on RUM without Limits, Datadog recommends keeping sessionSampleRate at 100% because metrics are computed from ingested sessions; lowering it reduces the RUM Measure charge but makes metrics proportionally less accurate
Documentation
Vendor references for pricing and configuration.