# 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.