Managing Opsgenie Deep

OpsGenie Advanced Management Skill

Deep management of OpsGenie routing rules, integrations, on-call analytics, and alert policies.

API Conventions

Authentication

All API calls use the Authorization: GenieKey XXXXXX header — injected automatically. Never hardcode tokens.

Base URL

https://api.opsgenie.com

Core Helper Function

#!/bin/bash

og_api() {
    local method="$1"
    local endpoint="$2"
    local data="${3:-}"

    if [ -n "$data" ]; then
        curl -s -X "$method" \
            -H "Authorization: GenieKey $OPSGENIE_API_KEY" \
            -H "Content-Type: application/json" \
            "https://api.opsgenie.com${endpoint}" \
            -d "$data"
    else
        curl -s -X "$method" \
            -H "Authorization: GenieKey $OPSGENIE_API_KEY" \
            "https://api.opsgenie.com${endpoint}"
    fi
}

Output Rules

• TOKEN EFFICIENCY: Extract only needed fields with jq
• Target ≤50 lines per script output
• Always filter by relevant time range to avoid huge response sets

Routing Rules Management

List Team Routing Rules

og_api GET "/v2/teams/TEAM_ID/routing-rules" | jq '[.data[] | {
  id, name, order,
  timezone,
  criteria: .criteria,
  notify: .notify
}]'

Create a Routing Rule

og_api POST "/v2/teams/TEAM_ID/routing-rules" '{
  "name": "High Priority to Primary",
  "order": 0,
  "criteria": {
    "type": "match-all-conditions",
    "conditions": [{"field": "priority", "operation": "equals", "expectedValue": "P1"}]
  },
  "notify": {"type": "escalation", "id": "ESCALATION_ID"}
}'

Integration Management

List All Integrations

og_api GET "/v2/integrations" | jq '[.data[] | {id, name, type, enabled, teamId: .ownerTeam.id}]'

Get Integration Details

og_api GET "/v2/integrations/INTEGRATION_ID" | jq '.data | {name, type, enabled, allowConfigurationAccess, suppressNotifications}'

On-Call Analytics

Get On-Call Schedule Timeline

og_api GET "/v2/schedules/SCHEDULE_ID/timeline?interval=1&intervalUnit=months" | jq '.data | {
  schedule: .name,
  rotations: [.finalTimeline.rotations[] | {
    name,
    periods: [.periods[] | {user: .recipient.name, start: .startDate, end: .endDate}]
  }]
}'

Who Is Currently On-Call

og_api GET "/v2/schedules/SCHEDULE_ID/on-calls" | jq '.data | {
  parent: .parent.name,
  onCallParticipants: [.onCallParticipants[] | {name, type}]
}'

Alert Policy Management

List Alert Policies

og_api GET "/v2/policies/alert" | jq '[.data[] | {id, name, type, enabled, order}]'

Analyze Alert Volume by Team

og_api GET "/v2/alerts?limit=100&sort=createdAt&order=desc" | jq '
  [.data[] | {team: .ownerTeamId, priority: .priority, status: .status}]
  | group_by(.team) | map({team: .[0].team, count: length, priorities: (group_by(.priority) | map({(.[0].priority): length}) | add)})
'

Notification Rules

List User Notification Rules

og_api GET "/v2/users/USER_ID/notification-rules" | jq '[.data[] | {
  id, name, actionType, enabled,
  steps: [.steps[] | {contact: .contact, sendAfter: .sendAfter}]
}]'

Common Tasks

1. Audit routing rules — verify all teams have proper routing for P1-P5 priorities
2. Analyze on-call burden — check schedule coverage and rotation fairness
3. Tune alert policies — adjust deduplication, suppression, and auto-close rules
4. Review integrations — ensure all monitoring tools are properly connected
5. Optimize notification rules — configure escalating notification channels per severity

Output Format

Present results as a structured report:

Managing Opsgenie Deep Report
═════════════════════════════
Resources discovered: [count]

Resource       Status    Key Metric    Issues
──────────────────────────────────────────────
[name]         [ok/warn] [value]       [findings]

Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]

Target ≤50 lines of output. Use tables for multi-resource comparisons.

Anti-Hallucination Rules

1. NEVER assume resource names — always discover via CLI/API in Phase 1 before referencing in Phase 2.
2. NEVER fabricate metric names or dimensions — verify against the service documentation or --help output.
3. NEVER mix CLI commands between service versions — confirm which version/API you are targeting.
4. ALWAYS use the discovery → verify → analyze chain — every resource referenced must have been discovered first.
5. ALWAYS handle empty results gracefully — an empty response is valid data, not an error to retry.

Counter-Rationalizations