Skip to content

Datadog

Datadog collects evidence from your app and the systems behind it. Browser monitoring shows what a page did, and a linked server trace can show where a request spent its time.

Visit Datadog

How can you follow a slow request from the page to the server?

Datadog calls browser monitoring Real User Monitoring, or RUM. It records events such as page views, clicks, resource loads and errors from captured sessions. Application Performance Monitoring, or APM, collects server traces. A trace shows the timed steps that services recorded while handling a request.

Create a browser application in Datadog and initialize its browser library with that application's client token, app ID and Datadog site. To link a browser request to a server trace, your developer needs a supported server tracer and must enable browser tracing for the first-party requests you intend to match. The matching browser and server evidence both need to be retained. The initial HTML load and requests made before the browser library starts are outside this linking flow.

How can you check one slow request in a disposable app?

Use a private demo page that loads fictional appointment slots from a same-origin test endpoint. Before opening it, verify the browser and server send only to a test monitoring setup. Check that the endpoint uses sample records and that live storage, sign-in, payments and email connections are disabled or replaced with test services. If you cannot verify the connections or have no approved test access, sketch the browser and server records on paper.

  1. Load the fictional list once
    Have the test endpoint return a fixed list after a short delay. Open the demo and wait for the browser library to start. Then load the list. Note the request time and route in the demo.
  2. Compare the browser timing with the trace
    In RUM Explorer, find the demo request and look for its linked server trace. Compare the time the browser waited with the steps the server recorded. If the trace is missing, check whether the browser request was enabled for tracing, the server reported a matching trace, and both sides kept the evidence.

Which data should you leave out before sending events?

Browser events can include the page address, request address and other details. Avoid putting private values in those addresses. Configure the browser library to redact supported fields before sending them. If you enable Session Replay, configure its page and input masking separately.

Retention filters decide which already received sessions to keep in detail. Apply privacy rules before sending browser data. Review separately what your server traces and logs include.

What makes the browser monitoring bill change?

The November 12, 2026 public price list shows separate monthly units of 1,000 sessions. Measure starts at US$0.15 for collected sessions. Investigate starts at US$3 for filtered sessions kept in detail. Session Replay starts at US$2.50 per 1,000 replay sessions as an add-on to Investigate. These are annual-commitment starting rates.

Check what fraction of visits the browser library sends and what fraction the retention filters keep. Retention quotas can limit some detailed session retention. Datadog lists 30 days for retained sessions and 15 days for resource, long-task and vital details. Check separate meters and terms for server tracing, logs and any archive or export add-on before estimating the total.

Which browser evidence can you keep outside Datadog?

RUM Explorer can download selected query results as CSV. The documented limits are up to 5,000 individual events or 500 supported aggregation results per export. A separate Export Pipelines add-on can send raw RUM data to your cloud storage.

Choose the export based on the evidence you need. A CSV query result gives you event rows or summaries. It does not give you a playable replay or a copy of all monitors and dashboards.