> ## Documentation Index
> Fetch the complete documentation index at: https://support.configview.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Datadog setup

ConfigView reads your Datadog organization through Datadog's API, using an **API key** and an **application key** that belongs to a **service account** you create for ConfigView.

You will end up with **2 secrets** in ConfigView (`DATADOG_API_KEY`, `DATADOG_APP_KEY`), plus a third (`DATADOG_SITE`) if your organization is not on Datadog's US1 site.

> **Scope of this integration today.** ConfigView reads who has Datadog and with what role, whether they use MFA and when they last signed in, every API and application key with its owner and last use, where each monitor sends its alerts, every outside service and cloud account Datadog is connected to, where log data is copied outside Datadog, this month's and last month's usage per product, and the Audit Trail of who changed what. ConfigView only reads. It never creates, changes or deletes anything, and it never reads alert text, log contents, metrics, dashboards or key values.

***

## Step 1: Open the Datadog page in ConfigView

Open ConfigView in a second browser tab and leave it open:

`https://{companyname}.configview.com/admin/integrations/datadog`

Datadog shows an application key once, when you create it, so paste it straight into ConfigView instead of keeping it in a notes file.

***

## Step 2: Find your Datadog site

Look at the address bar when you are signed in to Datadog:

| Address in your browser | `DATADOG_SITE` |
| - | - |
| `app.datadoghq.com` | leave it empty |
| `us3.datadoghq.com` | `us3.datadoghq.com` |
| `us5.datadoghq.com` | `us5.datadoghq.com` |
| `app.datadoghq.eu` | `datadoghq.eu` |
| `ap1.datadoghq.com` | `ap1.datadoghq.com` |
| `ap2.datadoghq.com` | `ap2.datadoghq.com` |
| `app.ddog-gov.com` | `ddog-gov.com` |

If you are not on `app.datadoghq.com`, paste the value into `DATADOG_SITE` under **Credentials** and click the save icon. Keys only work on their own site: a valid key sent to the wrong one is rejected.

***

## Step 3: Create a role with the read permissions ConfigView needs

Datadog's built-in **Datadog Read Only Role** covers monitors and log configuration, but not users, keys, integrations, usage or the Audit Trail. Add those with a small custom role.

1. Sign in to Datadog as an admin and open **Organization Settings → Roles**
2. If **New Role** is not shown, click the gear icon and **Enable** custom roles
3. Click **New Role**. Name it `ConfigView Reader`
4. Tick these permissions, all of them read-only:
   * `user_access_read` (users and roles)
   * `api_keys_read` (API keys)
   * `org_app_keys_read` (application keys across the organization)
   * `audit_logs_read` (Audit Trail)
   * `usage_read` (usage)
   * `integrations_read` (Slack, Teams, PagerDuty, Opsgenie, webhooks, Jira, ServiceNow, Okta, Cloudflare, Fastly, Confluent)
   * `aws_configuration_read`, `gcp_configuration_read`, `azure_configuration_read` (connected cloud accounts)
5. Click **Save**

If your organization cannot use custom roles, give the service account in the next step the **Datadog Admin Role** instead. The application key in Step 5 is limited to read scopes, so it still can't change anything.

***

## Step 4: Create a service account for ConfigView

Use a service account, not a person. An application key that belongs to a person is revoked automatically when that person's Datadog account is disabled, so collection would stop the day they leave.

1. Open **Organization Settings → Service Accounts** and click **New Service Account**
2. **Name:** `ConfigView`. **Email:** a team address you control (for example `it@yourcompany.com`)
3. **Roles:** `Datadog Read Only Role` **and** `ConfigView Reader`
4. Click **Create Service Account**

***

## Step 5: Create the application key on the service account

1. Open the `ConfigView` service account and go to its **Application Keys** section. Click **New Key** and name it `ConfigView`
2. Click **Edit scopes** (or **Scopes**) and limit the key to these scopes. A scoped key can do only what its scopes list, whatever roles its owner has:
   * `user_access_read`, `api_keys_read`, `org_app_keys_read`, `audit_logs_read`, `usage_read`
   * `integrations_read`, `aws_configuration_read`, `gcp_configuration_read`, `azure_configuration_read`
   * `monitors_read`, `logs_read_archives`, `logs_read_config`
3. Copy the key. Switch to the ConfigView tab, paste it into `DATADOG_APP_KEY` under **Credentials**, and click the save icon

You need the `service_account_write` permission (admins have it) to scope a service account's key.

***

## Step 6: Add an API key

Every Datadog request carries an API key as well. It only identifies your organization. Any existing API key works, or create one for ConfigView:

1. Open **Organization Settings → API Keys** and click **New Key**
2. Name it `ConfigView` and click **Create API key**
3. Copy the key, paste it into `DATADOG_API_KEY` under **Credentials**, and click the save icon

***

## Step 7: Connect and verify

1. Back on `https://{companyname}.configview.com/admin/integrations/datadog`, confirm the credentials show as saved
2. Click **Connect**. ConfigView creates its tables and schedules every collector at your default run time. Stop any you don't want under **Collectors**:

| Script | Notes |
| - | - |
| **Users** | Every Datadog user and service account: email, status (active, invited, disabled), whether MFA is on, last login, and the roles each one holds. |
| **Roles** | Datadog roles, built-in and custom: how many users hold each one and the permissions it grants. |
| **API Keys** | Datadog API keys: name, last four characters, who created each one and when it was last used. The keys themselves are never stored. |
| **Application Keys** | Datadog application keys across the organization: name, last four characters, what each one is allowed to do, its owner and when it was last used. The keys themselves are never stored. |
| **Alert Recipients** | Where each Datadog monitor sends its alerts: the Slack channel, webhook, PagerDuty service, Teams channel, Opsgenie service or email address named in it. The alert text itself is not stored. |
| **Connected Services** | Outside services Datadog is connected to: Slack, Microsoft Teams, PagerDuty, Opsgenie, webhooks, Jira, ServiceNow, Okta, Cloudflare, Fastly, Confluent, AWS, Google Cloud and Azure accounts, with the host each one points at. No credentials are stored. Runs after **Alert Recipients**. |
| **Log Destinations** | Where Datadog copies log data outside itself: log archives in S3, Google Cloud Storage or Azure, and log forwarding to Splunk, Elasticsearch, Microsoft Sentinel or any HTTP endpoint, with the bucket or host and which logs go there. |
| **Monthly Usage** | This month's and last month's Datadog usage per product (hosts, containers, log volume, custom metrics and so on): the monthly total, the busiest hour and how many hours reported. |
| **Audit Trail** | Who changed what in Datadog: each Audit Trail event's time, person, action, the dashboard, monitor, key or setting it touched, and the IP it came from. Kept as a growing history. Needs Audit Trail enabled on the Datadog plan. |

3. Click **Verify now**. The health check confirms both keys, then reads one record from each kind of data.

If a check fails:

* **"Datadog API key" fails with 403.** The API key is wrong, or your organization is on another site. Set `DATADOG_SITE` (Step 2).
* **"Datadog application key" fails.** The key was revoked, belongs to another organization, or belonged to a person who has since been disabled. Create a new one on the service account.
* **"DATADOG\_APP\_KEY holds a UUID".** You saved the application key's ID (shaped like `a1b2c3d4-...`, 36 characters) instead of the key itself (40 letters and digits). Datadog shows the key only once, when it is created; if you no longer have it, create a new application key on the service account and save that.
* **A check is skipped with "needs ...".** The permission it names is missing from the service account's roles or from the key's scopes. Add it and verify again.
* **"Audit Trail" is skipped.** Audit Trail isn't enabled for your organization, or `audit_logs_read` is missing. Everything else still works; the Audit Trail table stays empty.

***

## Data Tables

Once the scripts run, these tables are created in your database. Each includes a `run_at` column. Every table keeps only the newest run, except `datadog_audit_events`, which keeps every event ever collected.

| Table | Source | Key Columns |
| - | - | - |
| `datadog_users` | `GET /api/v2/users` | user\_id, uuid, email, handle, name, title, status, disabled, verified, service\_account, mfa\_enabled, created\_at, modified\_at, last\_login\_time, role\_ids, role\_names |
| `datadog_user_roles` | `GET /api/v2/users` (role relationships) | user\_id, email, role\_id, role\_name |
| `datadog_roles` | `GET /api/v2/roles`, `GET /api/v2/roles/{role_id}/permissions` | role\_id, name, user\_count, managed, receives\_permissions\_from, permission\_count, permission\_names, created\_at, modified\_at |
| `datadog_api_keys` | `GET /api/v2/api_keys` | key\_id, name, last4, category, remote\_config\_read\_enabled, created\_at, modified\_at, date\_last\_used, created\_by\_id, created\_by\_email, created\_by\_name, created\_by\_status |
| `datadog_application_keys` | `GET /api/v2/application_keys` | key\_id, name, last4, scopes, scope\_count, created\_at, last\_used\_at, owner\_id, owner\_email, owner\_name, owner\_status, owner\_service\_account |
| `datadog_monitor_notifications` | `GET /api/v1/monitor` | monitor\_id, monitor\_name, monitor\_type, overall\_state, priority, monitor\_tags, creator\_email, created\_at, modified\_at, muted, handle\_type, handle\_target, is\_template, from\_escalation |
| `datadog_integrations` | Slack, webhook, PagerDuty, Teams, Opsgenie, Jira, ServiceNow, Okta, Cloudflare, Fastly, Confluent, AWS, GCP and Azure integration endpoints | integration, account\_name, account\_id, target\_host, source, status, referenced\_by\_monitors, extra\_json |
| `datadog_log_destinations` | `GET /api/v2/logs/config/archives`, `GET /api/v2/logs/config/custom-destinations` | destination\_kind, destination\_id, name, destination\_type, target\_host, bucket, path, region, storage\_account, cloud\_account, state, enabled, include\_tags, log\_query |
| `datadog_usage` | `GET /api/v2/usage/hourly_usage` | usage\_month, product\_family, usage\_type, total\_value, peak\_hourly\_value, hours\_reported, first\_hour, last\_hour, org\_name |
| `datadog_audit_events` | `GET /api/v2/audit/events` | event\_id, event\_time, service, event\_name, event\_action, asset\_type, asset\_id, asset\_name, actor\_id, actor\_email, actor\_name, client\_ip, event\_status, message, tags |

***

## Things worth knowing

**One row per alert target.** `datadog_monitor_notifications` has a row for every target a monitor names (`handle_type` = `slack`, `webhook`, `pagerduty`, `teams`, `opsgenie`, `email`, ...). A monitor that names nobody gets a single row with `handle_type = 'none'`. Targets built from template variables (for example `@slack-{{team.name}}`) are kept as written and marked `is_template = 1`.

**Webhooks, PagerDuty services and Slack accounts are found through monitors.** Datadog has no API that lists them, so ConfigView looks up each one a monitor names. A webhook or PagerDuty service that a monitor names but Datadog doesn't have shows `status = 'not_found'`: those alerts go nowhere. A webhook nobody references can't be seen. Slack handles of the form `@slack-<channel>` don't name the workspace, so they're grouped in one row with `status = 'referenced'`.

**Webhooks are stored as hosts.** `target_host` is the host a webhook posts to, never the full URL, its headers or its payload, which can contain tokens.

**Usage: totals for volumes, peaks for counts.** `total_value` sums every hour of the month, which is right for volumes (log bytes, indexed events, spans). For counts of things (hosts, containers) read `peak_hourly_value`. Datadog reports usage up to 72 hours late, so the current month always trails a little.

**Audit Trail is incremental.** The first run reads up to 90 days back. Each later run reads from the newest stored event, and events are never deleted from the table. Audit Trail must be enabled for your organization. Without it the table stays empty and nothing fails.

**Application keys belong to people.** When a Datadog user is disabled, Datadog revokes the application keys they created. API keys they created keep working. Compare `created_by_status` on API keys to find keys whose creator has gone.

**Rate limits.** Datadog sets limits per endpoint and reports them on every response. ConfigView paces itself well below them and waits for the reset when one is nearly used up.

## What isn't collected

* API key and application key values. Only the name and last four characters
* Alert message text. Only the targets named in it
* Webhook URLs (only the host), custom headers and payloads
* Integration credentials: Okta and Confluent API keys, client secrets, AWS access keys and external IDs, Azure client secrets
* Change details inside Audit Trail events: the before and after values of an edited dashboard or monitor
* Logs, metrics, traces, dashboards and notebooks


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.