OpsGenie Collector
Query the OpsGenie REST API for on-call, escalation, and team data. Writes tool-agnostic .oncall.* fields. Experimental: Atlassian is sunsetting OpsGenie into Jira Service Management; new accounts cannot be created. Existing tenants still work; new users should wait for the JSM collector.
opsgenie to your lunar-config.yml:uses: github://earthly/lunar-lib/collectors/opsgenie@v1.0.5
What This Integration Collects
This integration includes 1 collector that gather metadata from your systems.
oncall
Queries the OpsGenie REST API for the component's team. Discovers the
team ID from the component's opsgenie/team-id meta annotation
(typically set by a company-specific cataloger via lunar catalog component --meta opsgenie/team-id <id>), or falls back to the
explicit team_id input for static org-wide cases. Fetches team
details, the team's first on-call schedule (with rotation
participants), and its escalation policy. Writes normalized data to
.oncall.service, .oncall.schedule, .oncall.escalation, and
.oncall.summary. Stores raw API responses under
.oncall.native.opsgenie.
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": "opsgenie",
"integration": "api"
},
"service": {
"id": "4513b7ea-3b91-438f-b7e4-e3e54af9147c",
"name": "Payments Team",
"status": "active"
},
"schedule": {
"exists": true,
"participants": 4,
"rotation": "weekly"
},
"escalation": {
"exists": true,
"levels": 3,
"policy_name": "Payments Escalation"
},
"summary": {
"has_oncall": true,
"has_escalation": true,
"min_participants": 4
},
"native": {
"opsgenie": { "...full OpsGenie API response..." }
}
}
}Configuration
Configure this collector in your lunar-config.yml.
Inputs
| Input | Required | Default | Description |
|---|---|---|---|
team_id
|
Required | — | OpsGenie team ID (UUID) to query. Optional if the component has an `opsgenie/team-id` meta annotation set by a cataloger. |
opsgenie_base_url
|
Optional |
https://api.opsgenie.com
|
OpsGenie API base URL. Use `https://api.eu.opsgenie.com` for the EU instance. |
Secrets
This collector requires the following secrets to be configured in Lunar:
| Secret | Description |
|---|---|
OPSGENIE_API_KEY
|
OpsGenie REST API key (read-only token with read access to teams, schedules, and escalations) |
Documentation
View on GitHubOpsGenie Collector
Collect on-call schedule and escalation data from the OpsGenie API.
⚠️ Experimental — OpsGenie is being sunset by Atlassian. opsgenie.com now redirects to atlassian.com, and new OpsGenie accounts can no longer be created. Atlassian is migrating OpsGenie functionality into Jira Service Management (JSM). Existing OpsGenie tenants (orgs that signed up before the migration) can continue to use this collector against the OpsGenie REST API. Anyone setting up on-call from scratch should use Jira Service Management; a JSM on-call collector is tracked separately.
Overview
This collector queries the OpsGenie REST API on a daily cron schedule to
gather on-call schedule, escalation policy, and team data. It discovers
the OpsGenie team ID from the component's opsgenie/team-id meta
annotation (set via lunar catalog component --meta opsgenie/team-id <id>, typically by a company-specific cataloger) or accepts an explicit
team_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 OpsGenie, PagerDuty, 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 | OpsGenie team 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.opsgenie |
object | Raw OpsGenie API responses |
Collectors
This integration provides the following collectors:
| Collector | Description |
|---|---|
oncall |
Fetches team, schedule, and escalation data from OpsGenie API |
Installation
Add to your lunar-config.yml:
collectors:
- uses: github://earthly/lunar-lib/collectors/opsgenie@v1.0.0
on: ["domain:your-domain"]
# with:
# team_id: "4513b7ea-3b91-438f-b7e4-e3e54af9147c" # Optional — falls back to catalog meta annotation
# opsgenie_base_url: "https://api.eu.opsgenie.com" # For EU-region accounts
Required secrets:
OPSGENIE_API_KEY— OpsGenie REST API key (read-only, with read access to teams, schedules, and escalations)
Team ID discovery
The collector resolves the OpsGenie team ID in this order:
- Catalog meta annotation — reads
opsgenie/team-idfrom the component's lunar catalog meta. Set vialunar catalog component --meta opsgenie/team-id <id>, typically invoked by a company-specific cataloger that knows which components map to which OpsGenie teams. This is the recommended approach for orgs where each component owns its own team. - Explicit
team_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 team ID). - Neither found — the collector exits cleanly with no data written.
EU vs US accounts
OpsGenie operates separate US and EU instances. Set opsgenie_base_url
to https://api.eu.opsgenie.com if your OpsGenie account is hosted in
the EU region. The default https://api.opsgenie.com targets the US
instance.
Inputs
| Input | Default | Description |
|---|---|---|
team_id |
(empty — falls back to catalog meta) | OpsGenie team UUID. Optional if opsgenie/team-id meta annotation is set. |
opsgenie_base_url |
https://api.opsgenie.com |
OpsGenie API base URL (use https://api.eu.opsgenie.com for EU accounts) |
Team-centric data model
OpsGenie organises on-call around teams; each team owns one or more schedules and one or more escalation policies. This collector picks the first schedule and first escalation owned by the configured team to populate the normalized .oncall.schedule and .oncall.escalation paths. Teams with multiple schedules or escalations (e.g. business-hours vs after-hours) will only surface one — the others remain available under .oncall.native.opsgenie for advanced policies.
The policies/oncall plugin reads from .oncall.* and works against either OpsGenie or PagerDuty data — pick whichever collector matches your tooling.
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 OpsGenie 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 200+ built-in guardrails.
AI agent rules & prompt files
Post-mortem action items
Security & compliance policies
Testing & quality requirements