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
1---2name: datadog3description: Queries Datadog monitors, metrics, logs, and dashboards via connected integration. Use when investigating alerts, APM traces, log patterns, or security signals in Datadog.4---56# Datadog78## Purpose910Use connected Datadog tooling to investigate monitors, metrics, logs, dashboards, and security signals—with correct time ranges, scopes, and tags—without inventing API results.1112## When to Use1314- User mentions Datadog monitors, metrics, logs, APM, RUM, or security signals.15- Triage firing or muted monitors and correlate metric/log evidence.16- Build or refine monitor queries, dashboards, or notebooks when write tools exist.17- Incident investigation when Datadog is the observability source of truth.1819## When NOT to Use2021- Grafana-only or CloudWatch-only environments → **grafana**, **cloudwatch**.22- SLO/error-budget policy design without Datadog data → **error-budget-management**, **monitor-slos**.23- Skill authoring in this repo → **create-skill** / **publish-skill**.2425## Expected Outcome2627- Evidence from monitors, timeseries, or log queries with timeframe and scope documented.28- Monitor IDs, tags, and links included when the API returns them.29- Clear statement when org/site or API keys are unavailable.3031## Inputs to Gather3233- Datadog site (e.g. `datadoghq.com` region) if not implicit in tools.34- Time window and timezone for the investigation.35- Service, env, host, or tag filters (`service:`, `env:`, etc.).36- Monitor ID/name, dashboard URL, or log query context from the user.3738## Workflow39401. Confirm Datadog MCP tools; read schemas for metric, log, and monitor operations.412. Establish timeframe and tag scope before querying.423. For alerts: get monitor status → event timeline → metric/log proof → threshold comparison.434. For exploration: start broad, narrow by tags; avoid inventing metric names.445. For writes (monitors/dashboards): confirm scope and notify user on production-impacting changes.456. Summarize with monitor IDs, queries used, and recommended follow-ups.4647## Domain guidance48491. **Scope tags early** — `service`, `env`, `host`, `version` reduce noise.502. **Monitor vs metric** — distinguish monitor evaluation from ad-hoc metric queries.513. **Logs + metrics** — correlate trace/log IDs with metric spikes when debugging errors.524. **Security signals** — treat as read-first; escalate per org process; do not auto-mute without approval.535. **Tool fidelity** — only call tools defined by the integration; never fabricate timeseries points.5455### Typical tasks5657| Task | Approach |58|------|----------|59| Firing monitor | Status → message/tags → metric query for window → recent events |60| Log investigation | Query with timeframe → pattern count → exemplar lines (redact PII) |61| Dashboard/monitor edit | Fetch existing definition → minimal change → validate query |6263### Examples6465**User:** "Why did the checkout error monitor fire?"66→ Load monitor, pull evaluation window metric/log evidence, list top `service`/`version` tags, compare to threshold.6768**User:** "Show error rate for `payments` in prod last hour."69→ Metric query with `service:payments` and `env:prod`, return series summary and spike timestamps.7071## Tool Availability Rules7273| Access | Behavior |74|--------|----------|75| Full tool access | Run queries and approved writes; verify responses. |76| Read-only | Investigate and recommend monitor/query changes without applying. |77| No integration | Stop; do not fabricate Datadog data. |7879### Related tool sets8081- `datadog`82- `custom-apis`8384## Review / Decision / Execution Criteria8586- Every conclusion ties to a query result or monitor state from tools.87- Use RFC3339/Unix times consistently in summaries.88- Distinguish muted, no-data, and alert states explicitly.8990## Output Format91921. Question and evaluated window.932. Monitor/log/metric findings (with query snippets or IDs).943. Tags or services implicated.954. Blockers or permission gaps.965. Next steps (fix, mute with approval, dashboard link).9798## Quality Bar99100- On-call ready: what fired, why (evidence), what to check next.101- No spreadsheet or A1-style patterns—Datadog is metrics/logs/monitors only.102103## Safety and Boundaries104105- Redact secrets and PII from log excerpts.106- Do not auto-mute or delete monitors in production without explicit approval.107- Do not fabricate monitor states or metric values.108109## Escalation / Dispatch Rules110111- Grafana correlation → **grafana** when dual-stacked.112- Reliability policy → **error-budget-management** when discussing release freezes.113- Post-incident docs → **postmortem-authoring**.114115## References116117- `skills/old_skills.json` (`datadog`) — legacy catalog (Sheets boilerplate removed).118- `skills/skill.instruction.md`, `skills/meta.instructions.md`
poly-gents