PagerDuty Collector
Query the PagerDuty API to collect on-call schedule, escalation policy, and current responder data. Normalizes results into the .oncall category for tool-agnostic policy evaluation.
pagerduty to your lunar-config.yml:uses: github://earthly/lunar-lib/collectors/pagerduty@v1.0.5
What This Integration Collects
This integration includes 1 collector that gather metadata from your systems.
oncall
Queries the PagerDuty REST API for the component's service. Discovers
the service ID from the component's pagerduty/service-id meta
annotation (typically set by a company-specific cataloger via
lunar catalog component --meta pagerduty/service-id <id>), or falls
back to the explicit service_id input for static org-wide cases.
Fetches service details, on-call schedule participants, and escalation
policy. Writes normalized data to .oncall.service, .oncall.schedule,
.oncall.escalation, and .oncall.summary. Stores the raw API response
under .oncall.native.pagerduty.
How Collectors Fit into Lunar
Lunar watches your code and CI/CD systems to collect SDLC data from config files, test results, IaC, deployment configurations, security scans, and more.
Collectors are the automatic data-gathering layer. They extract structured metadata from your repositories and pipelines, feeding it into Lunar's centralized database where guardrails evaluate it to enforce your engineering standards.
Learn How Lunar Works →Example Collected Data
This collector writes structured metadata to the Component JSON. Here's an example of the data it produces:
{
"oncall": {
"source": {
"tool": "pagerduty",
"integration": "api"
},
"service": {
"id": "PXXXXXX",
"name": "Payment API",
"status": "active"
},
"schedule": {
"exists": true,
"participants": 4,
"rotation": "weekly"
},
"escalation": {
"exists": true,
"levels": 3,
"policy_name": "Payment API Escalation"
},
"summary": {
"has_oncall": true,
"has_escalation": true,
"min_participants": 4
},
"native": {
"pagerduty": { "...full PagerDuty API response..." }
}
}
}Configuration
Configure this collector in your lunar-config.yml.
Inputs
| Input | Required | Default | Description |
|---|---|---|---|
service_id
|
Required | — | PagerDuty service ID to query (e.g. PXXXXXX). Optional if the component has a `pagerduty/service-id` meta annotation set by a cataloger. |
pagerduty_base_url
|
Optional |
https://api.pagerduty.com
|
PagerDuty API base URL |
Secrets
This collector requires the following secrets to be configured in Lunar:
| Secret | Description |
|---|---|
PAGERDUTY_API_KEY
|
PagerDuty REST API key (read-only token with service and oncall scopes) |
Documentation
View on GitHubPagerDuty Collector
Collect on-call schedule and escalation data from the PagerDuty API.
Overview
This collector queries the PagerDuty REST API on a daily cron schedule to
gather on-call schedule, escalation policy, and service data. It discovers
the PagerDuty service ID from the component's pagerduty/service-id meta
annotation (set via lunar catalog component --meta pagerduty/service-id <id>, typically by a company-specific cataloger) or accepts an explicit
service_id input for static org-wide cases. Results are written to the
.oncall category in a tool-agnostic format, so the same oncall policy
works regardless of whether the data comes from PagerDuty, OpsGenie, or
another provider.
Collected Data
This collector writes to the following Component JSON paths:
| Path | Type | Description |
|---|---|---|
.oncall.source |
object | Tool and integration metadata |
.oncall.service |
object | PagerDuty service ID, name, and status |
.oncall.schedule |
object | On-call schedule: exists flag, participant count, rotation type |
.oncall.escalation |
object | Escalation policy: exists flag, level count, policy name |
.oncall.summary |
object | Summary flags for quick policy evaluation |
.oncall.native.pagerduty |
object | Raw PagerDuty API responses |
Collectors
This integration provides the following collectors:
| Collector | Description |
|---|---|
oncall |
Fetches service, schedule, and escalation data from PagerDuty API |
Installation
Add to your lunar-config.yml:
collectors:
- uses: github://earthly/lunar-lib/collectors/pagerduty@v1.0.0
on: ["domain:your-domain"]
# with:
# service_id: "PXXXXXX" # Optional — falls back to catalog meta annotation
Required secrets:
PAGERDUTY_API_KEY— PagerDuty REST API key (read-only, with service and oncall scopes)
Service ID discovery
The collector resolves the PagerDuty service ID in this order:
- Catalog meta annotation — reads
pagerduty/service-idfrom the component's lunar catalog meta. Set vialunar catalog component --meta pagerduty/service-id <id>, typically invoked by a company-specific cataloger that knows which components map to which PagerDuty services. This is the recommended approach for orgs where each component has its own service. - Explicit
service_idinput — set inlunar-config.ymlfor static org-wide configurations, or when importing the collector multiple times with differenton:scopes (e.g. one import per domain, each with its own service ID). - Neither found — the collector exits cleanly with no data written.
Inputs
| Input | Default | Description |
|---|---|---|
service_id |
(empty — falls back to catalog meta) | PagerDuty service ID (e.g. PXXXXXX). Optional if pagerduty/service-id meta annotation is set. |
pagerduty_base_url |
https://api.pagerduty.com |
PagerDuty API base URL |
Open Source
This collector is open source and available on GitHub. Contribute improvements, report issues, or fork it for your own use.
Common Use Cases
Explore guardrails that use data from PagerDuty Collector.
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 100+ built-in guardrails.
AI agent rules & prompt files
Post-mortem action items
Security & compliance policies
Testing & quality requirements