Enforce Escalation Defined using data collected by Datadog Collector. Automatically check operational readiness standards on every PR.
How Datadog Collector Powers This Guardrail
The Datadog Collector gathers metadata from your service catalog, incident management systems. This data flows into Lunar's Component JSON, where the Escalation Defined 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.
Quick Start Configuration
Add both the collector and policy to your lunar-config.yml to enable this guardrail.
# Step 1: Enable the Datadog Collector
collectors:
- uses: github://earthly/lunar-lib/collectors/datadog@v1.0.5
# with: ...
# Step 2: Enable the On-Call Guardrails
policies:
- uses: github://earthly/lunar-lib/policies/oncall@v1.0.5
include: [escalation-defined]
# with: ...What Datadog Collector Collects
This collector gathers the following data that the Escalation Defined guardrail evaluates.
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.
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.
oncall
Queries Datadog On-Call for the component's team: its routing rules,
the escalation policy its fallback rule pages, and the first schedule
that policy targets. The team comes from the component's datadog/team meta
annotation or the team input, as a team handle or team ID. Does
nothing when neither is set. Writes .oncall.service, .oncall.schedule,
.oncall.escalation, and .oncall.summary for the tool-agnostic oncall
policy, with raw API responses under .oncall.native.datadog.
Example Data Flow
Here's an example of the data that Datadog Collector writes to the Component JSON, which Escalation Defined then evaluates.
{
"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):..." }
}
]
}
}
},
"oncall": {
"service": {
"id": "8f3b4c1e-6d2a-4b7e-9c1f-2a5d8e7b3c90",
"name": "Payments"
},
"escalation": {
"exists": true,
"levels": 2,
"policy_name": "Payments escalation",
"id": "b7a1e2d4-3c5f-4e6a-8b9c-0d1e2f3a4b5c"
},
"schedule": {
"exists": true,
"participants": 2,
"rotation": "weekly",
"id": "d4c3b2a1-9f8e-4d7c-a6b5-c4d3e2f1a0b9",
"name": "Payments primary"
},
"summary": {
"has_oncall": true,
"has_escalation": true,
"min_participants": 2
},
"native": {
"datadog": {
"team": { "...Teams API team object (when the team is given as a handle)..." },
"routing_rules": { "...routing rules response..." },
"escalation_policy": { "...escalation policy response..." },
"schedule": { "...schedule response..." }
}
},
"source": {
"tool": "datadog",
"integration": "api"
}
}
}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. |
team |
Required | — | Datadog team handle (e.g. `payments`) or team ID whose On-Call setup the `oncall` sub-collector reads. Optional if the component has a `datadog/team` meta annotation. |
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'`. |
On-Call Guardrails Inputs
| Input | Required | Default | Description |
|---|---|---|---|
min_participants |
Optional |
2
|
Minimum number of on-call rotation participants required |
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.
AI agent rules & prompt files
Post-mortem action items
Security & compliance policies
Testing & quality requirements