On-Call Guardrails
Enforce on-call operational readiness standards. Verify that services have an active on-call schedule, a multi-level escalation policy, and a minimum number of rotation participants. Works with any oncall-category collector (PagerDuty, OpsGenie, etc.).
oncall to your lunar-config.yml:uses: github://earthly/lunar-lib/policies/oncall@v1.0.5
Included Guardrails
This policy includes 3 guardrails that enforce standards for your operational readiness.
schedule-configured
Verifies that the service has an active on-call schedule by checking .oncall.schedule.exists is true. Fails if no on-call schedule data is present.
escalation-defined
Verifies that an escalation policy is configured for the service by checking .oncall.escalation.exists is true. Fails if no escalation data is present.
min-participants
Ensures the on-call rotation has at least a minimum number of participants to avoid single-person burnout. Checks .oncall.schedule.participants against the configurable min_participants threshold (default: 2).
How Guardrails Fit into Lunar
Lunar guardrails define your engineering standards as code. They evaluate data collected by integrations and produce pass/fail checks with actionable feedback.
Policies support gradual enforcement—from silent scoring to blocking PRs or deployments—letting you roll out standards at your own pace without disrupting existing workflows.
Learn How Lunar Works →Example Evaluated Data
This policy evaluates structured metadata from the Component JSON. Here's an example of the data it checks:
{
"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
}
}
}Required Integrations
This policy evaluates data gathered by one or more of the following integration(s).
Make sure to enable them in your lunar-config.yml.
Configuration
Configure this policy in your lunar-config.yml.
Inputs
| Input | Required | Default | Description |
|---|---|---|---|
min_participants
|
Optional |
2
|
Minimum number of on-call rotation participants required |
Documentation
View on GitHubOn-Call Guardrails
Enforce on-call schedule, escalation, and staffing standards for production services.
Overview
This policy validates that services have proper on-call operational readiness:
an active schedule, a configured escalation policy, and enough rotation
participants to avoid burnout. It reads from the tool-agnostic .oncall
category, so the same guardrails work whether the data comes from PagerDuty,
OpsGenie, or another incident management tool.
Policies
This plugin provides the following policies (use include to select a subset):
| Policy | Description |
|---|---|
schedule-configured |
Verifies an on-call schedule exists for the service |
escalation-defined |
Verifies an escalation policy is configured |
min-participants |
Ensures the rotation has enough participants (default: 2) |
Required Data
This policy reads from the following Component JSON paths:
| Path | Type | Provided By |
|---|---|---|
.oncall.schedule.exists |
boolean | pagerduty collector (or any oncall-category collector) |
.oncall.schedule.participants |
number | pagerduty collector |
.oncall.escalation.exists |
boolean | pagerduty collector |
Note: Ensure a collector that writes to the .oncall category is configured before enabling this policy.
Installation
Add to your lunar-config.yml:
policies:
- uses: github://earthly/lunar-lib/policies/oncall@v1.0.0
on: ["domain:your-domain"]
enforcement: report-pr
# include: [schedule-configured] # Only run specific checks
# with:
# min_participants: "3"
Examples
Passing Example
{
"oncall": {
"schedule": { "exists": true, "participants": 4, "rotation": "weekly" },
"escalation": { "exists": true, "levels": 3 }
}
}
Failing Example
{
"oncall": {
"schedule": { "exists": false },
"escalation": { "exists": true, "levels": 1 }
}
}
Failure message: "On-call schedule is not configured for this service"
Remediation
When this policy fails, you can resolve it by:
- schedule-configured: Create an on-call schedule in PagerDuty for the service and assign team members
- escalation-defined: Create an escalation policy in PagerDuty with at least one level
- min-participants: Add more team members to the on-call rotation (default minimum is 2)
Open Source
This policy is open source and available on GitHub. Contribute improvements, report issues, or fork it for your own use.
Common Use Cases
Explore how individual guardrails work with specific integrations.
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