# Reported issues for datadog-mcp

Pod holds 12 of 12 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [datadog-mcp](/mcp/datadog-mcp).

## Most discussed

### monitors get/update: expose the `options` object

## Summary

The `monitors` tool's `action: get` returns a simplified monitor view that omits the `options` object (notify_audit, renotify_interval, notify_no_data, no_data_timeframe, timeout_h, include_tags, escalation_message, silenced groups, etc.). Datadog's own GET `/api/v1/monitor/{id}` returns these, so they're being stripped by the MCP layer.

This makes `action: update` dangerous in practice because you can't see the current option values before changing them.

## Repro

```json
{ "actio

[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/51) · 2026-04-22 · closed · 4 comments

### slos get/update: `query` (numerator/denominator) is omitted from get, but required by update — round-trip edits impossible

## Summary

The `slos` tool's `action: get` returned SLO metadata (name, type, thresholds, timeframe, tags, status) but **omitted the `query` object** (`numerator` / `denominator` for metric SLOs, or `monitor_ids` for monitor SLOs). Datadog's own [GET /api/v1/slo/{slo_id}](https://docs.datadoghq.com/api/latest/service-level-objectives/#get-an-slos-details) returns these, so they were being stripped at the MCP layer.

This made `action: update` unusable for any field-level edit (tags, name, descr

[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/55) · 2026-05-13 · closed · 2 comments

### UX feedback from extended investigation session — DX improvements

## Context

Collected during a ~4h extended DevOps investigation session (Nginx 5XX monitor tuning). Session involved creating SLOs + burn-rate monitors, analyzing 60-day metrics, and auditing 30-day events. What worked well and what slowed the workflow down.

## What worked well

- `monitors`, `slos`, `events`, `metrics` action-based API is coherent and predictable
- Parallel calls work cleanly (created SLO + 2 monitors in one message)
- Events search returns structured JSON (jq-friendly)
- SLO

[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/49) · 2026-04-21 · closed · 2 comments

### preview action rejects valid Datadog is_match / is_exact_match tag conditionals

## Summary

The `monitors` tool `preview` action rejects monitor messages that use Datadog's **tag-variable conditionals** `{{#is_exact_match "...""...}}` and `{{#is_match "...""...}}`, even though these are valid, documented Datadog monitor message syntax.

## Error

```
MCP error -32603: EUNSUPPORTED_TEMPLATE_SYNTAX: loops are not supported
(found {{#is_exact_match "tag.name" "value"}}). Supported syntax is
{{variable.name}} and conditionals {{#name}}...{{/name}} / {{^name}}...{{/name}}
where 

[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/65) · 2026-06-17 · closed · 1 comment

### monitors update: `config` parameter is a free-form object — no schema, no guidance on which Monitor options pass through

## Problem

The `monitors action=update` (and `create`) tool accepts a `config: object, additionalProperties: {}` parameter. There is no schema, no enum of supported keys, and no documentation about what fields make it through to Datadog's underlying `PUT /api/v1/monitor/{id}`.

For common alert-tuning workflows — adjusting thresholds, renotify cadence, notify_audit, notification preset, escalation message, evaluation delay, etc. — callers can't tell whether the MCP will:
- Accept the field and 

[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/54) · 2026-05-05 · closed · 1 comment

### Events API doesn't expose `monitor-alert-event` / `monitor-audit-event` sources — counting actual monitor fires is impossible

## Problem

Counting how many times a monitor actually fired (state transitions OK→Alert, equivalently the Slack notifications it sent) is the most common operational question for alert-hygiene work. None of the existing actions answer it correctly:

| Tool | Returned for one always-Alert SLO burn-rate monitor over 7d | Issue |
|---|---|---|
| `monitors action=top` | 162 | Datadog logs an event every time the monitor re-evaluates while in Alert (≈1/min). Most aren't notifications. |
| `events ac

[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/53) · 2026-05-05 · closed · 1 comment

### Add tools for Logs Pipelines, Indexes, and Archives configuration

## Summary

The MCP currently exposes runtime logs access (`logs` search/aggregate), but not the **configuration** of Datadog's log management (pipelines, indexes, archives). These configs have fully-documented public APIs and would close a real investigation gap.

## Motivation

When investigating why certain logs are missing from monitors, alerts, or Watchdog analysis, operators need to verify:

- **Which pipeline processors are applied to a service's logs** (grok parsing, remappers, lookups)

[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/50) · 2026-04-22 · closed · 1 comment

### fix: SLO list action returns null for sli/errorBudgetRemaining/state

## Problem

The `slos` tool `list` action returns `null` for all status fields:

```json
{
  "status": {
    "sli": null,
    "errorBudgetRemaining": null,
    "state": "unknown"
  }
}
```

Meanwhile the Datadog UI shows the real values (e.g. SLI: 99.696%, error budget: -203%).

The `history` action correctly returns the SLI value, so the data is accessible — it's just missing from `list`.

## Root cause

The Datadog [List SLOs API](https://docs.datadoghq.com/api/latest/service-level-objectives/

[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/40) · 2026-02-10 · closed · 1 comment

## Most recent

### Feature: traces action=dependencies — return caller→callee edges instead of re-deriving the graph from aggregate

There is no first-class way to ask "who calls whom". Dependency direction is the main input for cascade root-cause analysis — deciding whether the alerting service is the cause or a victim of something downstream — and today every consumer has to re-derive it.

### What works today, and what it costs

`traces action=aggregate` with `groupBy: ["service", "peer.service"]` does produce caller→callee edges with counts. But getting there requires the caller to already know three things:

1. that `pee

[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/70) · 2026-07-27 · open · 0 comments

### traces action=aggregate silently truncates groupBy buckets — no cursor, no truncation flag in meta

`traces action=aggregate` with a `groupBy` can return a partial bucket list with nothing in the response indicating it is partial. A truncated aggregation is byte-for-byte indistinguishable from a complete one, so a consumer reads "this group has no rows" when the group simply was not in the returned page.

### Observed

- `groupBy: ["service", "peer.service"]`, `limit: 100` → **39 buckets returned**, ordered alphabetically by the first key and cut off partway through the alphabet. Every service

[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/69) · 2026-07-27 · open · 0 comments

### monitors action=mute ignores 'scope' param — mutes the entire monitor instead of the group

## Summary
`monitors` tool, `action=mute` with a `scope` argument does not mute the targeted multi-alert group scope — it mutes the **whole monitor**.

## Steps to reproduce
Call the mute action on a multi-alert monitor with a group scope:

```
monitors action=mute id=123456 scope=host:web-01
```

## Expected
Only the `host:web-01` group is silenced:
```json
"silenced": { "host:web-01": null }
```
(equivalent to Datadog `POST /api/v1/monitor/{id}/mute?scope=host:web-01`)

## Actual
The entire mo

[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/68) · 2026-07-15 · open · 0 comments

### datadog_url in traces/logs results opens in live 'past 15 min' instead of the queried time window

The `traces` and `logs` tools return a `datadog_url` so users can open the query in the Datadog UI. The URL includes the time range (`start`/`end` for APM, `from_ts`/`to_ts` for logs), but it does **not** lock the time picker, so the UI opens in **live mode** and immediately resets to the default *Past 15 minutes* window — the queried range is lost. This is especially visible when querying historical windows (e.g. several days ago): the link lands on "now − 15 min", showing no data.

### Cause
T

[Read the thread](https://github.com/TANTIOPE/datadog-mcp-server/issues/67) · 2026-06-30 · open · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/tantiope/datadog-mcp-server/issues).