Monitor Has Pager Target + Datadog Collector

✓ Guardrail ↓ Collector Experimental Operational Readiness

Enforce Monitor Has Pager Target using data collected by Datadog Collector. Automatically check operational readiness standards on every PR.

Guardrail: Verifies that every Datadog monitor for the service routes to at least one pager target. Datadog monitors embed notification handles directly in the monitor message body using @handle syntax (e.g. `@pagerduty-core`, `@opsgenie-platform`, `@slack-oncall`). The policy scans each monitor's message field and fails if any monitor has no matching `@<pager_prefix>-*` handle. The prefix list is configurable via the `pager_handle_prefixes` input so teams can declare which notification routes count as "pager" (defaults cover PagerDuty, Opsgenie, VictorOps). Skips cleanly when the Datadog collector hasn't written native data.

Data Source: Query the Datadog API for dashboards, monitors, and SLOs linked to each component. Normalizes to .observability for tool-agnostic policies; raw data at .observability.native.datadog.

Get Started View on GitHub

How Datadog Collector Powers This Guardrail

The Datadog Collector gathers metadata from your service catalog systems. This data flows into Lunar's Component JSON, where the Monitor Has Pager Target guardrail evaluates it against your standards.

When enabled, this check runs automatically on every PR and in AI coding workflows, providing real-time enforcement with actionable feedback.

↓ Datadog Collector Gathers Data Collector

Extracts metadata from code, configs, and tool outputs

{ } Component JSON

Data centralized in structured format for evaluation

✓ Monitor Has Pager Target Checks Guardrail

Pass/fail result with actionable feedback in PRs

Quick Start Configuration

Add both the collector and policy to your lunar-config.yml to enable this guardrail.

📄 lunar-config.yml

# Step 1: Enable the Datadog Collector
collectors:
  - uses: github://earthly/lunar-lib/collectors/datadog@v1.0.5
    # with: ...

# Step 2: Enable the Datadog Guardrails
policies:
  - uses: github://earthly/lunar-lib/policies/datadog@v1.0.5
    include: [monitor-has-pager-target]
    # with: ...

What Datadog Collector Collects

This collector gathers the following data that the Monitor Has Pager Target guardrail evaluates.

Collector code

`service`

Queries the Datadog REST API for the component's monitors, dashboard, and SLOs. Discovers the Datadog service tag from the component's datadog/service-name meta annotation (typically set by a company-specific cataloger via lunar catalog component --meta datadog/service-name <name>), or falls back to the explicit service_name input for static cases. Optionally resolves a dashboard UUID from the datadog/dashboard-id meta or the dashboard_id input — dashboards in Datadog are not universally tagged with service:, so they must be mapped explicitly. Monitors (via /api/v1/monitor) and SLOs (via /api/v1/slo) are filtered by the service:<name> tag; dashboard is fetched by UUID when set. Writes normalized data to .observability.dashboard, .observability.alerts (monitors), .observability.slo, and .observability.source, with raw API responses under .observability.native.datadog.api.

Collector code

`repo-files`

Walks the component repository looking for Datadog-as-code JSON files by content fingerprint. Dashboards are identified by a top-level widgets array plus a layout_type field (the shape produced by Datadog's dashboard JSON export and the datadog_dashboard_json Terraform resource). Monitors are identified by a top-level object with type (e.g. metric alert, query alert, service check), query, and name fields. Users can narrow the scan by setting the find_command input (e.g. to restrict to a datadog/ directory); by default the full repo is walked. Writes each matching file's raw JSON (plus its repo path) into .observability.native.datadog.repo_dashboards and .observability.native.datadog.repo_monitors for users to build custom policies against. This sub-collector does not write to normalized .observability.dashboard / .observability.alerts paths — the API sub-collector owns those; repo files only surface raw content.

Example Data Flow

Here's an example of the data that Datadog Collector writes to the Component JSON, which Monitor Has Pager Target then evaluates.

{ } component.json From Datadog Collector

{
  "observability": {
    "source": {
      "tool": "datadog",
      "integration": "api"
    },
    "dashboard": {
      "id": "abc-123-def",
      "exists": true,
      "url": "https://app.datadoghq.com/dashboard/abc-123-def"
    },
    "alerts": {
      "configured": true,
      "count": 7
    },
    "slo": {
      "defined": true,
      "count": 2,
      "has_error_budget": true
    },
    "native": {
      "datadog": {
        "api": {
          "service_tag": "payment-api",
          "monitors": [ "...list of Datadog monitor objects..." ],
          "dashboard": { "...full Datadog dashboard API response..." },
          "slos": [ "...list of SLO objects..." ]
        },
        "repo_dashboards": [
          {
            "path": "datadog/payment-api-overview.json",
            "dashboard": { "title": "Payment API", "layout_type": "ordered", "widgets": [] }
          }
        ],
        "repo_monitors": [
          {
            "path": "datadog/monitors/latency.json",
            "monitor": { "name": "High p99 latency", "type": "metric alert", "query": "avg(last_5m):..." }
          }
        ]
      }
    }
  }
}

Configuration Options

Datadog Collector Inputs

Input	Required	Default	Description
`datadog_site`	Optional	`datadoghq.com`	Datadog site (e.g. `datadoghq.com`, `datadoghq.eu`, `us3.datadoghq.com`). Used to build API URLs and dashboard links. Defaults to the US1 site.
`service_name`	Required	—	Datadog service tag value (e.g. `payment-api`). Optional if the component has a `datadog/service-name` meta annotation set by a cataloger. Monitors and SLOs are filtered by `service:<name>`.
`dashboard_id`	Required	—	Datadog dashboard UUID (e.g. `abc-123-def`). Optional if the component has a `datadog/dashboard-id` meta annotation. Dashboards in Datadog are not universally tagged with `service:`, so they must be mapped explicitly.
`find_command`	Optional	`find . -type f -name '*.json'`	Command used by the `repo-files` sub-collector to enumerate candidate JSON files (must output one path per line). Narrow this to restrict the scan to a subdirectory, e.g. `find ./datadog -type f -name '*.json'`.

Datadog Guardrails Inputs

Input	Required	Default	Description
`pager_handle_prefixes`	Optional	`pagerduty,opsgenie,victorops`	Comma-separated list of Datadog notification handle prefixes that count as a pager target. Any monitor message containing at least one `@<prefix>-*` handle from this list passes the `monitor-has-pager-target` check. Defaults cover PagerDuty, Opsgenie, and VictorOps.

Learn More

Guardrail · Datadog Guardrails Monitor Has Pager Target View all compatible integrations

→

Collector Datadog Collector View full documentation

→

Ready to Automate Your Standards?

See how Lunar can turn your AGENTS.md, engineering wiki, compliance docs, or postmortem action items into automated guardrails with our 200+ built-in guardrails.

Works with any process

AI agent rules & prompt files

Post-mortem action items

Security & compliance policies

Testing & quality requirements

Automate Now

Paste your AGENTS.md or manual process doc and get guardrails in minutes

Book a Demo