# Datadog

> Queries Datadog monitors, metrics, logs, and dashboards via connected integration. Use when investigating alerts, APM traces, log patterns, or security signals in Datadog.

- Skill: `poly-gents/datadog` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add poly-gents/datadog`
- Raw SKILL.md: https://api.skillmd.com/api/skills/poly-gents/datadog/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: poly-gents (https://skillmd.com/u/poly-gents)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/poly-gents/datadog

---


# Datadog

## Purpose

Use connected Datadog tooling to investigate monitors, metrics, logs, dashboards, and security signals—with correct time ranges, scopes, and tags—without inventing API results.

## When to Use

- User mentions Datadog monitors, metrics, logs, APM, RUM, or security signals.
- Triage firing or muted monitors and correlate metric/log evidence.
- Build or refine monitor queries, dashboards, or notebooks when write tools exist.
- Incident investigation when Datadog is the observability source of truth.

## When NOT to Use

- Grafana-only or CloudWatch-only environments → **grafana**, **cloudwatch**.
- SLO/error-budget policy design without Datadog data → **error-budget-management**, **monitor-slos**.
- Skill authoring in this repo → **create-skill** / **publish-skill**.

## Expected Outcome

- Evidence from monitors, timeseries, or log queries with timeframe and scope documented.
- Monitor IDs, tags, and links included when the API returns them.
- Clear statement when org/site or API keys are unavailable.

## Inputs to Gather

- Datadog site (e.g. `datadoghq.com` region) if not implicit in tools.
- Time window and timezone for the investigation.
- Service, env, host, or tag filters (`service:`, `env:`, etc.).
- Monitor ID/name, dashboard URL, or log query context from the user.

## Workflow

1. Confirm Datadog MCP tools; read schemas for metric, log, and monitor operations.
2. Establish timeframe and tag scope before querying.
3. For alerts: get monitor status → event timeline → metric/log proof → threshold comparison.
4. For exploration: start broad, narrow by tags; avoid inventing metric names.
5. For writes (monitors/dashboards): confirm scope and notify user on production-impacting changes.
6. Summarize with monitor IDs, queries used, and recommended follow-ups.

## Domain guidance

1. **Scope tags early** — `service`, `env`, `host`, `version` reduce noise.
2. **Monitor vs metric** — distinguish monitor evaluation from ad-hoc metric queries.
3. **Logs + metrics** — correlate trace/log IDs with metric spikes when debugging errors.
4. **Security signals** — treat as read-first; escalate per org process; do not auto-mute without approval.
5. **Tool fidelity** — only call tools defined by the integration; never fabricate timeseries points.

### Typical tasks

| Task | Approach |
|------|----------|
| Firing monitor | Status → message/tags → metric query for window → recent events |
| Log investigation | Query with timeframe → pattern count → exemplar lines (redact PII) |
| Dashboard/monitor edit | Fetch existing definition → minimal change → validate query |

### Examples

**User:** "Why did the checkout error monitor fire?"
→ Load monitor, pull evaluation window metric/log evidence, list top `service`/`version` tags, compare to threshold.

**User:** "Show error rate for `payments` in prod last hour."
→ Metric query with `service:payments` and `env:prod`, return series summary and spike timestamps.

## Tool Availability Rules

| Access | Behavior |
|--------|----------|
| Full tool access | Run queries and approved writes; verify responses. |
| Read-only | Investigate and recommend monitor/query changes without applying. |
| No integration | Stop; do not fabricate Datadog data. |

### Related tool sets

- `datadog`
- `custom-apis`

## Review / Decision / Execution Criteria

- Every conclusion ties to a query result or monitor state from tools.
- Use RFC3339/Unix times consistently in summaries.
- Distinguish muted, no-data, and alert states explicitly.

## Output Format

1. Question and evaluated window.
2. Monitor/log/metric findings (with query snippets or IDs).
3. Tags or services implicated.
4. Blockers or permission gaps.
5. Next steps (fix, mute with approval, dashboard link).

## Quality Bar

- On-call ready: what fired, why (evidence), what to check next.
- No spreadsheet or A1-style patterns—Datadog is metrics/logs/monitors only.

## Safety and Boundaries

- Redact secrets and PII from log excerpts.
- Do not auto-mute or delete monitors in production without explicit approval.
- Do not fabricate monitor states or metric values.

## Escalation / Dispatch Rules

- Grafana correlation → **grafana** when dual-stacked.
- Reliability policy → **error-budget-management** when discussing release freezes.
- Post-incident docs → **postmortem-authoring**.

## References

- `skills/old_skills.json` (`datadog`) — legacy catalog (Sheets boilerplate removed).
- `skills/skill.instruction.md`, `skills/meta.instructions.md`