Connect your toolsSources

Connect Datadog

Connect Datadog so Adduce reads the monitors that are alerting and how many error lines each of your services logged today.

Adduce reads the Datadog monitors that are alerting right now, and how many error lines each of your services logged in the last day, so the operational picture sits beside what customers said.

Beta

This connector works, but it has not been proven against a real customer account yet, so Adduce badges it Beta wherever it appears. Tell us at hello@adducehq.com if what you see does not match this page.

Before you begin

  • Role: project Editor or Lead. A workspace Admin is a lead on every project.
  • In Datadog: permission to create an API key and a scoped application key.
  • To hand: your Datadog site, both keys, and the monitor tags or log query if you want to narrow what is read.
  • Time: ten minutes.

What Adduce reads

SurfaceWhat it becomes
Monitors in the alert stateEvidence naming the monitor, its type, when it last triggered and its first few tags
Error logs per serviceEvidence naming the service, how many error lines it logged in the last day, and the most recent message — for the 25 services with the most error lines

Both are pain points, and both are a snapshot: each sync re-reads the current state and refreshes what it already holds. A monitor that stops alerting keeps its evidence — the outage happened — and is matched on its numeric id, so renaming it in Datadog does not orphan anything.

Permissions the keys need

KeyScopeWhy
API keynone to setidentifies your organisation on every call
Application keymonitors_readread the monitors that are alerting
Application keylogs_read_datacount error lines, and read one sample message per service

Create the application key under a service account and scope it. An unscoped key inherits every permission its owner has, which is far more than Adduce reads. Some organisations also need logs_read_index_data. Nothing is written.

Steps

In Datadog, open Organization Settings → API Keys and copy an API key. The page footer also names your site.

Open Organization Settings → Application Keys, create a key under a service account, and scope it to monitors_read and logs_read_data.

In Adduce, open the project, choose Sources, then Add source, and choose the Datadog tile.

Callout 1: the Datadog tile, in Observability and badged Beta.

On Connection details, name the source, choose your site, and paste both keys. Monitor tags and Log query narrow what is read; leave them empty for every monitor and every error log.

Callout 1: the Datadog site. Callout 2: the scoped application key.

Choose Continue. Adduce makes the two reads the sync itself makes — one for monitors, one for logs — so an application key that is missing either scope fails here rather than on the first sync.

Back on Sources, the new row shows Connected, and a signal count once the first sync has run — or Error, as the row here does, when Datadog has rejected the keys. The first question below is where to start on that.

Callout 1: the status of a Datadog row. This one is in error — its keys were rejected.

First sync and cadence

There is no backfill. Every sync reads the monitors alerting at that moment and the last twenty-four hours of error logs, grouped by service, and refreshes what it already holds. The first sync and the hundredth read the same window. Adduce syncs once a day at 03:00 UTC, and Sync now runs one immediately.

Monitors and logs are read separately, so one failing still lets the other through, and one service whose sample message cannot be fetched loses only that line, not its count. If both fail the run is marked failed, rather than completing empty and reading as a quiet day.

Disconnect or replace credentials

Delete the source from its page and type its name to confirm. Deleting removes the evidence it produced. To rotate either key, or to change the tags or the query, delete the source and add it again; the next sync reads the same trailing day, so nothing is lost.

If it did not work

Why were the keys rejected for monitors?

Datadog answers the same way for every bad-credential case, so check all three at once: the API key, the application key, and the site. A key from a US organisation does not work against the EU site.

Why did monitors work but logs fail?

The application key can read monitors but not log data. Re-scope it to include logs_read_data, and add logs_read_index_data if your organisation restricts index access.

Why is a busy service missing from the evidence?

Only the 25 services with the most error lines are recorded, so a service that is busy but quieter than those falls outside the list. After that, only indexed logs are visible at all: logs excluded by an index filter, or sent straight to archives, are not counted, however many there are. The Log query you entered narrows it further, on top of the fixed error filter.

What's next

On this page