Skip to content
Datadog Monitors

Datadog Monitors Skill

Create and audit Datadog monitors from an agent via the pup CLI — with alerting rules that stop the usual flapping, unscoped and unowned monitors.

GitHub Docs

Install

Install with the skills CLI

One command for Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf and dozens of other agents. Needs Node.js; the skill is fetched straight from datadog-labs/agent-skills.

$ npx skills add datadog-labs/agent-skills --skill dd-monitors

Run it in a terminal. The CLI finds the agents installed on your machine, asks which ones to add the skill to, and whether to install it into the folder you ran it from or for all your projects.

Other ways to install

Copy the whole skill folder — SKILL.md and any scripts or references beside it — into ~/.claude/skills/dd-monitors/, where Claude Code picks it up in every project. Only git is needed.

tmp=$(mktemp -d) && \
  git clone --depth 1 --branch main https://github.com/datadog-labs/agent-skills.git "$tmp" && \
  mkdir -p ~/.claude/skills && \
  cp -R "$tmp"/dd-monitors ~/.claude/skills/dd-monitors

No scripts or references next to it? Saving the SKILL.md alone as ~/.claude/skills/dd-monitors/SKILL.md works too.

Using another agent? Its personal skills folder
Codex
~/.agents/skills/
Cursor
~/.cursor/skills/
GitHub Copilot
~/.copilot/skills/
Gemini CLI
~/.gemini/skills/
Windsurf
~/.codeium/windsurf/skills/
OpenCode
~/.config/opencode/skills/

About

  • List, inspect and create monitors through the pup CLI
  • Alerting rules that prevent flapping and unscoped queries
  • Recovery thresholds and runbook-bearing notification templates
  • jq audits for unowned and noisy monitors
  • Downtime-versus-edit guidance for planned silence
  • Refuses direct deletion — marks monitors for human review instead

Most monitor problems are not "the alert did not fire" — they are alerts that fire constantly and get muted, or alerts scoped to {*} that page someone for a host nobody owns. This official Datadog skill teaches an agent both halves: driving the pup CLI to list, inspect and create monitors, and the judgement to make the monitor worth having.

The alerting standard it enforces

The guidance is opinionated in the way alerting guidance has to be. Evaluation windows use last_5m rather than last_1m, because a one-minute window on CPU is a flap generator. Queries must be scoped by env and service and grouped by host, not left as {*}. Recovery thresholds are treated as mandatory rather than optional — a critical at 80 with a critical_recovery at 70 is what keeps a monitor from oscillating across the line. Notification bodies carry template variables, a runbook and the on-call handles, so the page arrives with the context needed to act on it.

Auditing what already exists

Beyond creation, the skill includes jq recipes for the two audits nobody runs: finding monitors with no team: tag, and ranking monitors by recent state churn to surface the noisiest ones. It also draws the distinction between downtime and monitor edits — planned silence belongs in a downtime window (pup downtime create), not in a threshold change that quietly alters behaviour forever.

A deletion guard

Notably, the skill instructs the agent never to delete a monitor directly. Instead it renames it with a [MARKED FOR DELETION] prefix, so a human confirms the removal. That is the sort of guard rail worth having when an agent is operating alerting configuration.

Covers the full monitor type table (metric, query, service check, event, log, composite, APM) and a failure-handling table mapping symptoms to fixes. Requires the pup CLI, authenticated with pup auth login. MIT-licensed, published by Datadog Labs, and works with Claude Code, Codex CLI, Gemini CLI, Cursor, Windsurf and OpenCode.

SKILL.md

The instructions your agent loads, as published by Datadog.

SKILL.md
name
dd-monitors
description
Monitor management - list, search, file-based create, and alerting best practices.
metadata
version: "1.0.1" author: datadog-labs repository: https://github.com/datadog-labs/agent-skills tags: datadog,monitors,alerting,alerts,dd-monitors globs: "**/datadog*.yaml,**/*monitor*" alwaysApply: "false"

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:

  1. Check context first (prior outputs, conversation, saved values).
  2. If a required value is missing, run a discovery command first.
  3. If still ambiguous, ask the user to confirm.
  4. Then run the target command.
  5. 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
RuleWhy
No flapping alertsUse last_Xm not last_1m
Meaningful thresholdsBased on SLOs, not guesses
Actionable alertsIf 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
TypeUse Case
metric alertCPU, memory, custom metrics
query alertComplex metric queries
service checkAgent check status
event alertEvent stream patterns
log alertLog pattern matching
compositeCombine multiple monitors
apmAPM 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
UseWhen
DowntimeAny planned silence window
Monitor editQuery/threshold behavior changes
# Downtime (preferred)
pup downtime create --file downtime.json
Failure Handling
ProblemFix
Alert not firingCheck query returns data, thresholds
Too many alertsIncrease window, add recovery threshold
No data alertsCheck agent connectivity, metric exists
Auth errorpup auth refresh
References
Install

Official Datadog skill for the pup CLI — OAuth2 login with token refresh, plus a command map covering logs, monitors, traces, metrics, incidents, SLOs, on-call, security signals and audit logs.

Browse all skills →