Skip to content
Reoclo Reoclo Reoclo Docs

PagerDuty Notifications

Reoclo triggers PagerDuty incidents via the Events API v2 so that on-call rotations, escalation policies, and acknowledgement workflows all kick in automatically. Severity maps directly onto PagerDuty’s critical/warning/info levels with an option to override.

When to use it

Section titled “When to use it”
  • You want Reoclo events to page someone on rotation
  • You already use PagerDuty for incident lifecycle (ack, resolve, escalate)
  • You want alerts to deduplicate by event source

For chat-only delivery, use Slack or Microsoft Teams. For an alternative paging tool, see OpsGenie.

Prerequisites

Section titled “Prerequisites”
  • A PagerDuty account with at least one service
  • Permission to add integrations to that service

Step 1 — Create the Events API integration

Section titled “Step 1 — Create the Events API integration”
  1. In PagerDuty, open Services and pick the service that should receive Reoclo incidents (or create a new one).
  2. Open the Integrations tab.
  3. Click Add another integration (or Add an integration if it’s a new service).
  4. Pick Events API V2 from the integration type list and click Add.
  5. Expand the new integration row and copy the Integration Key — it’s a 32-character hex string. This is your “routing key” in the Events API.

Each Reoclo channel maps to one PagerDuty service. If you want different events to page different teams, create one Reoclo channel per service.

Step 2 — Create the channel in Reoclo

Section titled “Step 2 — Create the channel in Reoclo”

Dashboard

Section titled “Dashboard”
  1. Open Settings → Notification Channels.
  2. Click Add Channel → PagerDuty.
  3. Give it a name (e.g., prod-oncall).
  4. Paste the Integration Key into Integration Key.
  5. (Optional) Configure the Severity Map if your service expects different PagerDuty severities — see below.
  6. Click Send Test — a [TEST] Reoclo notification channel test incident should appear in PagerDuty within a few seconds with severity info.
  7. Pick which events this channel receives. For paging, you typically want deploy_failed, monitoring_uptime_down, incident_created, and security_ip_conflict.
  8. Save.
  9. Resolve or acknowledge the test incident in PagerDuty so your on-call isn’t paged.

CLI

Section titled “CLI”
Terminal window
reoclo channels create pagerduty \
  --name "prod-oncall" \
  --secret "<32-char-integration-key>" \
  --events deploy_failed,monitoring_uptime_down,incident_created

Or via YAML with a custom severity map:

kind: pagerduty
name: prod-oncall
config:
  severity_map:
    critical: critical
    warn: error
    info: warning
secret: ${env:PAGERDUTY_INTEGRATION_KEY}
events:
  deploy_failed: true
  monitoring_uptime_down: true
  incident_created: true
  security_ip_conflict: true

Severity mapping

Section titled “Severity mapping”

Reoclo carries one of three severities into PagerDuty’s payload.severity field:

Reoclo severityDefault PagerDuty severity
criticalcritical
warnwarning
infoinfo
noneinfo

Override on a per-channel basis by setting severity_map in the config:

config:
  severity_map:
    critical: critical
    warn: error      # bump warns to "error" instead of "warning"
    info: warning    # treat info as warning so it still notifies

Valid PagerDuty severities are critical, error, warning, info.

Payload

Section titled “Payload”

Reoclo posts to https://events.pagerduty.com/v2/enqueue:

{
  "routing_key": "<your-integration-key>",
  "event_action": "trigger",
  "payload": {
    "summary": "Deployment failed",
    "source": "reoclo",
    "severity": "critical",
    "custom_details": {
      "body": "Deployment of MyApp to prod-1 failed: exit code 137 (OOM)",
      "deployment_id": "dep-abc123",
      "application_name": "MyApp"
    }
  }
}

PagerDuty’s 202 Accepted is treated as success. Reoclo always sends event_action: trigger — it does not currently emit acknowledge or resolve actions, so use PagerDuty’s UI or API to close the resulting incidents.

Troubleshooting

Section titled “Troubleshooting”
SymptomCauseFix
400 Invalid routing keyWrong key copied (e.g., a service ID instead of integration key)Copy the 32-char Integration Key from the Events API V2 integration row
429 Too many requestsExceeded PagerDuty’s 480 events/min per integration keyReoclo retries with backoff; for very high volume, split across multiple integrations
Incidents missing custom_detailsOlder alert rules without rich metadataUpdate the alert rule’s payload; defaults work for all built-in events
Severity always infoEvent isn’t alert-driven (e.g., deploy_started)Expected — only alert-fired events carry severity. Non-alert events default to info
Test passes, real events silentEvent toggles disabledOpen the channel and enable the events you want

Routing tips

Section titled “Routing tips”
  • One Reoclo channel per PagerDuty service. That’s how you route different events to different teams.
  • Avoid sending info events to a paging service — they create noise that erodes trust in pages. Either filter at the Reoclo level (don’t enable info-class events) or map info to warning and configure PagerDuty service rules to suppress.
  • Pair with chat for context. Page via PagerDuty, but also send the same events to a Slack channel so the team has shared context when triaging.

Next Steps

Section titled “Next Steps”