datadog-labs/agent-skills/dd-monitors/SKILL.md
dd-monitors
Monitor management - list, search, file-based create, and alerting best practices.
- Source repository stars
- 158
- Declared platforms
- 0
- Static risk flags
- 2
- Last source update
- 2026-08-21
- Source checked
- 2026-08-25
Decision brief
What it does: where it fits
Create, manage, and maintain monitors for alerting.
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/datadog-labs/agent-skills --skill "dd-monitors"Inspect the Agent Skill "dd-monitors" from https://github.com/datadog-labs/agent-skills/blob/47d0cf5096fed4e7191e1f8eb2b2dc69cc135f10/dd-monitors/SKILL.md at commit 47d0cf5096fed4e7191e1f8eb2b2dc69cc135f10. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
Quick Start
Review the “Quick Start” section in the pinned source before continuing.
Review and apply the “Quick Start” source section. - 02
Prerequisites
This requires pup in your path. See Setup Pup.
This requires pup in your path. See Setup Pup. - 03
Command Execution Order (Token-Efficient)
For scoped commands, use this order:
Check context first (prior outputs, conversation, saved values).If a required value is missing, run a discovery command first.If still ambiguous, ask the user to confirm. - 04
Common Operations
Review the “Common Operations” section in the pinned source before continuing.
Review and apply the “Common Operations” source section. - 05
List Monitors
Review the “List Monitors” section in the pinned source before continuing.
Review and apply the “List Monitors” source section.
Permission review
Static risk signals and limitations
Runs scripts
The documentation asks the agent to run terminal commands or scripts.
If a required value is missing, run a discovery command first.Runs scripts
The documentation asks the agent to run terminal commands or scripts.
Then run the target command.Writes files
The documentation asks the agent to create, modify, or delete local files.
pup monitors create --file monitor.jsonWrites files
The documentation asks the agent to create, modify, or delete local files.
pup downtime create --file downtime.jsonEvidence record
Why each signal appears
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 93/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 158 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- datadog-labs/agent-skills
- Skill path
- dd-monitors/SKILL.md
- Commit
- 47d0cf5096fed4e7191e1f8eb2b2dc69cc135f10
- License
- MIT
- Collected
- 2026-08-25
- Default branch
- main
View the original SKILL.md
Datadog Monitors
Create, manage, and maintain monitors for alerting.
Prerequisites
This requires pup in your path. See Setup Pup.
Command Execution Order (Token-Efficient)
For scoped commands, use this order:
- Check context first (prior outputs, conversation, saved values).
- If a required value is missing, run a discovery command first.
- If still ambiguous, ask the user to confirm.
- Then run the target command.
- Avoid speculative commands likely to fail.
Quick Start
pup auth login
Common Operations
List Monitors
pup monitors list
pup monitors list --tags "team:platform"
Get Monitor
pup monitors get <id>
Create Monitor
pup monitors create --file monitor.json
Silence Alerts (Downtime)
# No pup monitors mute/unmute commands.
# Use downtime payloads to silence monitor notifications.
pup downtime create --file downtime.json
pup downtime cancel <downtime_id>
Monitor Creation Best Practices
1. Avoid Alert Fatigue
| Rule | Why |
|---|---|
| No flapping alerts | Use last_Xm not last_1m |
| Meaningful thresholds | Based on SLOs, not guesses |
| Actionable alerts | If no action needed, don't alert |
| Include runbook | @runbook-url in message |
# WRONG - will flap constantly
query = "avg(last_1m):avg:system.cpu.user{*} > 50" # ❌ Too sensitive
# CORRECT - stable alerting
query = "avg(last_5m):avg:system.cpu.user{env:prod} by {host} > 80" # ✅ Reasonable window
2. Use Proper Scoping
# WRONG - alerts on everything
query = "avg(last_5m):avg:system.cpu.user{*} > 80" # ❌ No scope
# CORRECT - scoped to what matters
query = "avg(last_5m):avg:system.cpu.user{env:prod,service:api} by {host} > 80" # ✅
3. Set Recovery Thresholds
monitor = {
"query": "avg(last_5m):avg:system.cpu.user{env:prod} > 80",
"options": {
"thresholds": {
"critical": 80,
"critical_recovery": 70, # ✅ Prevents flapping
"warning": 60,
"warning_recovery": 50
}
}
}
4. Include Context in Messages
message = """
## High CPU Alert
Host: {{host.name}}
Current Value: {{value}}
Threshold: {{threshold}}
### Runbook
1. Check top processes: `ssh {{host.name}} 'top -bn1 | head -20'`
2. Check recent deploys
3. Scale if needed
@slack-ops @pagerduty-oncall
"""
NEVER Delete Monitors Directly
Use safe deletion workflow (same as dashboards):
def safe_mark_monitor_for_deletion(monitor_id: str, client) -> bool:
"""Mark monitor instead of deleting."""
monitor = client.get_monitor(monitor_id)
name = monitor.get("name", "")
if "[MARKED FOR DELETION]" in name:
print(f"Already marked: {name}")
return False
new_name = f"[MARKED FOR DELETION] {name}"
client.update_monitor(monitor_id, {"name": new_name})
print(f"✓ Marked: {new_name}")
return True
Monitor Types
| Type | Use Case |
|---|---|
metric alert | CPU, memory, custom metrics |
query alert | Complex metric queries |
service check | Agent check status |
event alert | Event stream patterns |
log alert | Log pattern matching |
composite | Combine multiple monitors |
apm | APM metrics |
Audit Monitors
# Find monitors without owners
pup monitors list | jq '.[] | select(.tags | contains(["team:"]) | not) | {id, name}'
# Find noisy monitors (high alert count)
pup monitors list | jq 'sort_by(.overall_state_modified) | .[:10] | .[] | {id, name, status: .overall_state}'
Downtime vs Muting
| Use | When |
|---|---|
| Downtime | Any planned silence window |
| Monitor edit | Query/threshold behavior changes |
# Downtime (preferred)
pup downtime create --file downtime.json
Failure Handling
| Problem | Fix |
|---|---|
| Alert not firing | Check query returns data, thresholds |
| Too many alerts | Increase window, add recovery threshold |
| No data alerts | Check agent connectivity, metric exists |
| Auth error | pup auth refresh |
References
Frequently asked questions
What to verify before installation and use
What does the dd-monitors source document cover?
Create, manage, and maintain monitors for alerting.
How do I install dd-monitors?
The source record exposes this install command: npx skills add https://github.com/datadog-labs/agent-skills --skill "dd-monitors". Inspect the command and pinned source before running it.
Which permission-related actions were detected?
Static rules flagged exec-script, write-files in the source; the page lists the matching lines and excerpts.
Alternatives
Compare before choosing
garrytan/gbrain
bulk-ingestion
End-to-end discipline for turning any large data source (audio libraries, email takeouts, document corpora, chat exports, API dumps) into brain pages at scale. The lifecycle spine: SCHEMA → ACCESS → TRIAL → EVALUATE → IMPROVE → CODIFY → TEST → SKILLIFY → BULK → MONITOR. State is tracked in a durable JSON manifest (see MANIFEST-PATTERN.md) so any crash, session boundary, or subagent fan-out resumes from ground truth instead of memory.
alirezarezvani/claude-skills
app-store-optimization
App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist
wanshuiyin/Auto-claude-code-research-in-sleep
citation-audit
Use it for operations and research tasks; the detail page covers purpose, installation, and practical steps.
prowler-cloud/prowler
postgresql-indexing
PostgreSQL indexing best practices for Prowler: index design, partial indexes, partitioned table indexing, EXPLAIN ANALYZE validation, concurrent operations, monitoring, and maintenance. Trigger: When creating or modifying PostgreSQL indexes, analyzing query performance with EXPLAIN, debugging slow queries, reviewing index usage statistics, reindexing, dropping indexes, or working with partitioned table indexes. Also trigger when discussing index strategies, partial indexes, or index maintenance