| name | datadog |
| description | Queries Datadog monitors, metrics, logs, and dashboards via connected integration. Use when investigating alerts, APM traces, log patterns, or security signals in 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
- Confirm Datadog MCP tools; read schemas for metric, log, and monitor operations.
- Establish timeframe and tag scope before querying.
- For alerts: get monitor status → event timeline → metric/log proof → threshold comparison.
- For exploration: start broad, narrow by tags; avoid inventing metric names.
- For writes (monitors/dashboards): confirm scope and notify user on production-impacting changes.
- Summarize with monitor IDs, queries used, and recommended follow-ups.
Domain guidance
- Scope tags early —
service, env, host, version reduce noise.
- Monitor vs metric — distinguish monitor evaluation from ad-hoc metric queries.
- Logs + metrics — correlate trace/log IDs with metric spikes when debugging errors.
- Security signals — treat as read-first; escalate per org process; do not auto-mute without approval.
- 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
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
- Question and evaluated window.
- Monitor/log/metric findings (with query snippets or IDs).
- Tags or services implicated.
- Blockers or permission gaps.
- 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
