Open-source alternative to Dynatrace RUM and Session Replay

Correlation between a replayed session and a backend trace depends on one shared identifier: the trace context that the browser sends with each API request. The OpenReplay tracker records the user's session, including clicks, network activity and JavaScript errors, and stores it under its own session identifier. The backend services emit OpenTelemetry traces. When the browser request carries a W3C traceparent header, the backend span joins the same trace, and the trace ID can then be matched to the failing user action. Without that header, the two records exist side by side with nothing linking them.

The OpenTelemetry Collector sits between the services and the storage backends as a gateway. It receives OTLP data from many services, applies processing such as batching and attribute handling, and exports traces to a backend such as Jaeger, while metrics and logs go to their own destinations. Running it as a gateway gives one place to enforce which attributes leave the network and to change backends without touching application code. Decide which telemetry crosses the trust boundary from the browser, and confirm that the Collector's receiver authentication and exporter credentials, described in the configuration best practices, are set before any browser-originated data reaches it.

Verify propagation in your own stack before relying on it. Check that your front-end and API domains are configured for the trace headers you expect, that your load balancers, API gateways and reverse proxies forward traceparent and tracestate unchanged, and that cross-origin requests allow those headers in CORS settings. Then send one test user action, find the session in OpenReplay, and confirm the matching trace appears in your tracing backend. Record which services drop the context, because a single proxy that strips headers will break correlation for every user journey that passes through it.

Capture-time sanitization is the control that matters most in session replay, because OpenReplay's README describes masking or skipping data before it reaches the server. That means personal data that is masked in the browser never has to be stored in the replay backend in readable form. Your team has three settings to work with: masking by CSS selector, which hides chosen elements such as account numbers or address blocks; input redaction, which hides what users type into form fields; and private mode, which masks all text and inputs by default and lets you unmask only the elements you have reviewed.

Before go-live, the first decision is which fields count as personal data in your product. That list usually includes names, email addresses, phone numbers, national identifiers, payment details, health or financial information, and free-text fields where users describe their situation. Your privacy and legal teams should own that inventory and sign off on it. Once it exists, test the masking rules against real page flows in a staging environment: fill every form with dummy values, play back the recordings, and confirm that each sensitive value is hidden. Repeat the test after every front-end release, since a renamed class or a new component can silently remove a selector. Confirm with OpenReplay how its masking behaves for your framework and for native mobile replay.

Self-hosting changes where the residual risk sits. OpenReplay's README notes that self-hosting keeps session data in your own infrastructure, so recordings, retention settings and access logs are under your control rather than a third party's. Your team still owns the hosting, backup, access roles and deletion process, and those need written procedures. Whether masking and retention meet your legal obligations is a determination for your privacy and legal teams and, where relevant, your independent auditors, not something this page or DeployOpen decides.

The main gap is front-end instrumentation. Dynatrace's real user monitoring is built around its own agent, which captures browser and mobile sessions and correlates them with backend services without much manual setup. OpenTelemetry does not yet offer a stable real user monitoring specification, so there is no equivalent standard to lean on for browser telemetry. OpenReplay covers session replay, browser errors and session-to-trace linking, but the team should expect to add and maintain its own tracker configuration, and should confirm which Dynatrace-driven automatic capture (for example, specific user actions or page load timings) needs a manual equivalent. Also confirm how Dynatrace's AI-assisted analysis of user journeys and anomalies maps to what your team will do by hand in OpenReplay and its dashboards.

Several features need confirmation in your own environment rather than assumption. Mobile replay is listed for iOS, Android and React Native, so check which SDK versions, frameworks and app architectures your teams actually ship. Cobrowsing uses WebRTC calls, which depends on your network paths, TURN infrastructure and browser policies. Product analytics features such as funnels, journeys and heatmaps should be compared with the reports your analysts rely on today, including how each handles retention and segmentation. Ask OpenReplay for its current documentation on each capability and test the exact configuration you plan to deploy.

Before cutover, build a short test plan from your own use cases. Pick a few critical journeys, such as login, checkout or a regulated form, and verify that masking rules hide the fields your privacy team cares about in both the replay and the error payloads. Run the browser tracker alongside your current tool for a defined period, and compare whether sessions link to the correct backend traces. Record every Dynatrace view your on-call and product teams use weekly, and assign an owner for each gap that remains open. Any capability that cannot be reproduced should be a documented decision, not a surprise after the commercial agreement ends.