Skip to main content
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: 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:
  1. 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.

​
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