How to Tell If a Website Uses Datadog

Datadog is one of the dominant enterprise observability platforms, and on the front end it shows up as Real User Monitoring (RUM) — a browser agent that measures real visitors' performance, errors and behaviour. Because Datadog is infrastructure for engineering and operations teams rather than marketing technology, detecting its RUM agent tells you a great deal about the organisation. The fastest way to confirm it is to open the Network tab and look for requests to browser-intake-datadoghq.com, or to type DD_RUM into the console. This guide covers every reliable signal, the agent mechanics behind them, and what the find reveals.

What is Datadog RUM?

Datadog is a broad monitoring platform spanning infrastructure metrics, application performance monitoring (APM), log management, security monitoring and more. Its front-end product, Real User Monitoring, runs a small JavaScript agent in the browser that records how the site actually performs for real visitors: page-load timings and Core Web Vitals, JavaScript errors, resource loading, and user actions and views as people navigate. That data flows into Datadog, where engineering and operations teams correlate front-end behaviour with back-end traces and infrastructure metrics to diagnose problems end to end.

The key point for detection is that Datadog is operations and engineering infrastructure, not a marketing tool. It is licensed enterprise software, often expensive at scale, and it requires engineers to instrument it. So when you find Datadog RUM on a site, you are almost always looking at a well-resourced organisation with a serious approach to reliability and performance — frequently one with dedicated platform-engineering or site-reliability functions. Datadog RUM commonly appears alongside Datadog's server-side APM, so the browser agent is often just the visible tip of a much larger Datadog deployment behind the scenes.

How Datadog RUM loads and sends data

A Datadog RUM install loads the browser agent — datadog-rum.js — from www.datadoghq-browser-agent.com, or bundles the @datadog/browser-rum npm package directly into the application. It then calls DD_RUM.init({ applicationId: '...', clientToken: '...', site: 'datadoghq.com', ... }) to configure monitoring. The applicationId identifies the specific RUM application within the customer's Datadog account, and the clientToken authorises the browser to send data. If browser logging is also enabled, a parallel DD_LOGS agent is initialised the same way.

Once running, the agent batches performance metrics, errors, views and user actions and POSTs them to Datadog's browser-intake endpoints — *.browser-intake-datadoghq.com for US accounts, or region-specific hosts such as browser-intake-datadoghq.eu for EU data residency and other Datadog sites. These intake requests fire frequently as the visitor navigates, which is characteristic of a RUM tool. The site parameter in the configuration tells you which Datadog region the account uses, a small but useful piece of intelligence. Understanding this flow — agent load, init() with app credentials, frequent intake POSTs — makes the detection signals straightforward.

How to tell if a website uses Datadog

Confirm at least two of the following.

1. View the page source and bundles. Search for datadog, DD_RUM, datadoghq-browser-agent or applicationId. Even bundled installs usually leave the DD_RUM references and the intake configuration in the application code.

2. Check the Network tab. This is the most reliable method. Reload the page, navigate a little, and filter for datadog or browser-intake. You will see frequent POSTs to *.browser-intake-datadoghq.com (or the EU equivalent), and possibly the datadog-rum.js agent download from datadoghq-browser-agent.com.

3. Use the console. Type DD_RUM and press Enter. A Datadog RUM page returns the global object exposing init, addAction, startView and related methods. Typing DD_LOGS reveals whether browser logging is also enabled.

4. Read the init configuration. Wherever you find DD_RUM.init({ applicationId: '...', clientToken: '...' }), those identifiers confirm Datadog and identify the monitored application and region.

5. Look for the npm package. References to @datadog/browser-rum or @datadog/browser-logs in the bundle confirm a bundled install and the exact products in use.

What the Datadog signals look like

window.DD_RUM.init({ applicationId: "abc-123", clientToken: "pubXYZ", site: "datadoghq.com", service: "web-app" });
GET  https://www.datadoghq-browser-agent.com/datadog-rum.js
POST https://rum.browser-intake-datadoghq.com/api/v2/rum?...   (batched RUM data)
window.DD_RUM = { init: ƒ, addAction: ƒ, startView: ƒ, ... }

The combination of the DD_RUM global, the datadoghq-browser-agent.com agent, and POSTs to a browser-intake-datadoghq host is conclusive.

Datadog versus similar tools — avoiding false positives

Datadog RUM sits in the observability category alongside New Relic Browser, Sentry, Dynatrace, Elastic APM, Grafana Faro and others, so match the exact fingerprint. Datadog uses the DD_RUM/DD_LOGS globals and browser-intake-datadoghq.com; New Relic uses the NREUM global and bam.nr-data.net; Sentry uses window.Sentry and ingest.sentry.io; Dynatrace uses dtrum and dynatrace.com beacons. They all do real-user and error monitoring, but their globals and intake hosts are distinct. Because RUM batches data and sends it frequently, do not mistake the steady stream of intake requests for a performance problem — that traffic is the monitoring. And remember that Datadog's front-end RUM is often only part of a larger Datadog deployment whose server-side components you cannot see from the browser.

How reliable is each Datadog signal?

The POSTs to a browser-intake-datadoghq host are definitive, as is the DD_RUM global with a readable init configuration. The applicationId and clientToken in that configuration are equally conclusive and identify the application. The datadoghq-browser-agent.com agent download is a strong confirmation when present, though bundled installs may not show a separate file. References to @datadog/browser-rum in the bundle are reliable. The weakest signal is a stray "datadog" string with no global or intake traffic. Lean on the intake requests and the DD_RUM global, both of which are unambiguous and survive bundling.

What a Datadog install reveals about a company

Datadog RUM is a strong enterprise-engineering signal. It is licensed, can be costly at scale, and requires engineers to instrument — so its presence marks a well-resourced organisation that takes reliability and performance seriously, frequently with a dedicated platform-engineering, DevOps or SRE function. Because RUM is usually one module of a broader Datadog subscription that also covers infrastructure, APM and logs, finding the browser agent often implies a much larger Datadog footprint and a meaningful annual contract. If you sell developer or observability tooling, cloud infrastructure, performance consulting or engineering services, a Datadog install identifies a technically mature, budget-bearing account that already invests in monitoring. The service and env tags sometimes visible in the configuration can even hint at how the company structures its applications and environments.

Datadog in a modern engineering stack

Datadog RUM almost always sits within a substantial cloud-native stack. Teams running it typically operate on a major cloud provider, deploy through CI/CD, and use Datadog (or a comparable platform) for back-end APM, infrastructure metrics and log aggregation, with RUM closing the loop on front-end experience. The front end itself is usually a modern framework, and you may find Datadog alongside a feature-flag tool, a CDN with its own analytics, and an error tracker — sometimes Datadog handles errors itself, sometimes Sentry runs in parallel. For an auditor, the valuable details are the applicationId and service name, the Datadog region from the site parameter, whether DD_LOGS indicates logging is also enabled, and which framework the front end uses; together these reveal both the scale of the Datadog investment and the shape of the engineering organisation behind it.

A quick Datadog confirmation walkthrough

Open the site with developer tools on the Console panel and type DD_RUM — a returned object with init and startView confirms Real User Monitoring; also try DD_LOGS to see whether logging is enabled. Switch to the Network tab, filter for browser-intake or datadog, and navigate the site to see the steady stream of intake POSTs. In the Sources panel, search for DD_RUM.init to read the applicationId, clientToken, site and service values. The DD_RUM global plus a browser-intake-datadoghq request is enough to confirm, while the init configuration provides the application-level detail that makes the finding actionable.

A quick Datadog detection checklist

• Filter the Network tab for browser-intake; POSTs to browser-intake-datadoghq.* are conclusive.
• Type DD_RUM (and DD_LOGS) in the console to confirm the agents.
• Search the bundles for DD_RUM.init, applicationId and clientToken.
• Note the datadoghq-browser-agent.com agent download if present.
• Read the site parameter to identify the Datadog region (US vs EU).
• Treat steady intake traffic as normal monitoring, not a performance issue.

Detecting Datadog at scale

One page is a quick console check, but profiling many domains for enterprise observability — for instance, to find well-resourced engineering organisations — needs automation. StackOptic detects Datadog RUM and thousands of other technologies from a real browser, so you can surface monitoring-led companies across a whole list and infer the broader stack each one implies. For related reading, see checking what JavaScript libraries a website uses and the Datadog technology profile.