# Datadog Synthetics Bot: User Agent, Headers and IPs

> How to identify Datadog Synthetic Monitoring requests: the Datadog/Synthetics user agent, the sec-datadog header, IP ranges and analytics filters.

Datadog Synthetic Monitoring sends scheduled test requests to websites and APIs. It is not a crawler: a Datadog customer creates each test and gives it the URLs to visit. If you see this traffic in your logs, identify it with the documented headers and IP ranges. Then allow it or filter it out of your analytics.

## What sends the requests

Datadog is a monitoring service. Its [Synthetic Monitoring](https://docs.datadoghq.com/synthetics/) product runs simulated requests and browser actions from locations around the world. API tests send requests to endpoints over HTTP, SSL, DNS and other protocols. Browser tests load pages in a real browser and do the steps that the test owner recorded.

Tests run from Datadog managed locations or from private locations. A private location is a test runner that a customer installs in its own network ([Datadog docs](https://docs.datadoghq.com/synthetics/platform/private_locations/)).

## User agent and headers

Datadog lists these defaults in [Identify Synthetic Bots](https://docs.datadoghq.com/synthetics/guide/identify_synthetics_bots/):

| Test type | Default user agent |
|---|---|
| API tests (single and multistep) | `Datadog/Synthetics` |
| Browser tests | Changes with the browser and device, and always ends with `DatadogSynthetics` |

A test owner can set a custom user agent. The custom value replaces the default one.

Datadog adds a `sec-datadog` header to all requests from Synthetic tests. The value includes the ID of the test. For API tests, it looks like this:

```
sec-datadog: Request sent by a Datadog Synthetics API Test (https://docs.datadoghq.com/synthetics/) - test_id:
```

Browser tests send the same header with "Browser Test" in place of "API Test". API and browser tests also send APM headers, for example `x-datadog-origin: synthetics`.

## IP ranges

Datadog publishes the IP ranges of each managed location at `https://ip-ranges. /synthetics.json`. For the datadoghq.com site, the file is [ip-ranges.datadoghq.com/synthetics.json](https://ip-ranges.datadoghq.com/synthetics.json). The ranges use CIDR notation (an address block such as `192.0.2.0/24`).

Datadog says that the ranges rarely change, except when it adds a new managed location. Tests from private locations do not use these ranges. Their requests come from the network of the customer that runs them.

## Remove test visits from analytics

Browser tests set the variable `window._DATADOG_SYNTHETICS_BROWSER` to `true`. If you do not want test visits in your analytics, start your analytics only when the variable is not set:

```javascript
if (window._DATADOG_SYNTHETICS_BROWSER === undefined) {
initializeAnalytics()
}
```

On Firefox, Datadog cannot guarantee that the variable is set before your code runs. Browser tests also set the cookies `datadog-synthetics-public-id` and `datadog-synthetics-result-id`.

## Allow or block the traffic

Datadog does not say that Synthetic tests read robots.txt. A test requests the URL that its owner configured.

If your own team runs the tests, make sure that your firewall or bot protection lets them through. Allow the Datadog IP ranges, or match the `sec-datadog` header. If the firewall blocks the tests, they fail.

If tests that you do not own load your site, block them on your server or firewall. Match the user agent or the IP ranges. The block makes those tests fail. It has no effect on search engines or AI crawlers. For similar monitoring traffic, see [New Relic Synthetics](/ai-crawler-bot/newrelic-synthetics/) and [Pingdom](/ai-crawler-bot/pingdom/).

---

[View the canonical page](https://aichatwatch.com/ai-crawler-bot/datadog/) · [Browse llms.txt](https://aichatwatch.com/llms.txt)