**TL;DR:** DD_SITE tells the agent which Datadog region your org lives in. US1 is datadoghq.com, EU is datadoghq.eu, plus us3, us5, ap1, ap2 and gov sites. The agent installs fine, starts fine, and your hosts never appear. The tracers default to US1, so EU/APAC orgs must set it or traces go nowhere. - API calls: the API hostname changes too, e.g. https://api.datadoghq.eu for EU.

# Datadog site parameter: match it to your org or nothing works

This is the number one silent failure in Datadog setups. The agent installs fine, starts fine, and your hosts never appear. Nine times out of ten it is the site.

## The table (from the docs, Access the Datadog site)

| Your org lives at | DD_SITE / site parameter |
|---|---|
| app.datadoghq.com (US1) | datadoghq.com |
| us3.datadoghq.com | us3.datadoghq.com |
| us5.datadoghq.com | us5.datadoghq.com |
| app.datadoghq.eu (EU1, Germany) | datadoghq.eu |
| ap1.datadoghq.com (Japan) | ap1.datadoghq.com |
| ap2.datadoghq.com | ap2.datadoghq.com |
| app.ddog-gov.com (US1-FED) | ddog-gov.com |

Rule: look at the URL in your browser when you log into Datadog. That domain minus `app.` and the scheme is your site parameter.

## Where it goes

- **Host agent**: `site:` in `datadog.yaml`, or `DD_SITE` in the environment when you run the installer.
- **Containers**: `DD_SITE` env var on the agent container. The docs call this out explicitly as one of the two required container env vars alongside `DD_API_KEY`.
- **Tracers/SDKs**: `DD_SITE` env var. The tracers default to US1, so EU/APAC orgs must set it or traces go nowhere.
- **API calls**: the API hostname changes too, e.g. `https://api.datadoghq.eu` for EU. The API reference lists every regional endpoint.

## How to confirm you got it right

After install, `datadog-agent status` shows the site the agent is reporting to. If the agent is up but the host never appears in Infrastructure, check that line first. A 403 on intake payloads is the other classic symptom: your key is valid, just valid in a different region.

## Trap

Docs and blog posts almost always show `datadoghq.com` examples. If your org is EU or APAC, copy-pasting those examples without changing the site is exactly how you end up debugging a ghost.

## When to use this

- This covers exactly what the title says: Datadog DD_SITE.
- You are setting this up for the first time, or auditing an existing setup.
- You want the key gotchas in one place before you start.

## When not to use this

- You are doing a different workflow with Datadog; these steps are specific to the title above.
- You need the full reference docs; this is the short path, not the manual.

## Compatibility

- Not pinned to a specific version; follows current Datadog behavior.

---

## Vectle citations

- Exact version: <https://vectle.com/skills/skl_2U0nGcmKetKnrAV4xrxvxg/versions/skv_IonGJfqOHP3iNIeWwzjAkg>
- Canonical HTML skill page: <https://vectle.com/skills/skl_2U0nGcmKetKnrAV4xrxvxg>
- Current Markdown URL: <https://vectle.com/skills/skl_2U0nGcmKetKnrAV4xrxvxg/markdown>

## Selected public attribution and original notices/references

```json
{
  "author": "issueatlas",
  "client": null,
  "notices_and_references": [
    "https://docs.datadoghq.com/getting_started/site/",
    "https://docs.datadoghq.com/getting_started/agent/"
  ]
}
```