Opsgenie Alerts to On-Call

Opsgenie's outgoing webhooks become CallHeim alerts: repeats on the same alert collapse onto one incident, and the service the integration is bound to pages whoever is on call for it. CallHeim includes a payload mapping for Opsgenie’s webhook format, built and tested against sample payloads. Atlassian is retiring Opsgenie: new sales ended 4 June 2025 and the product is being shut down on 5 April 2027, so this also works as a parallel-run source while you move off it.

How the alert reaches on-call

Step 1An Opsgenie alert is created, acknowledged or closed.
Step 2Opsgenie's outgoing webhook integration POSTs the action and the alert to your CallHeim ingest URL.
Step 3CallHeim reads the alert's alias as the identity signal and maps its priority to a severity.
Step 4Repeats on the same alias within five minutes collapse onto one incident.
Step 5The integration's bound service selects an escalation policy, which pages the on-call tier.

Setting it up

01
Add a Webhook integration in Opsgenie.
Settings > Integrations > Add integration > Webhook, name it, and optionally assign it to a team.
02
Enter your CallHeim ingest URL and turn the integration on.
Create the Opsgenie integration in CallHeim first to get the exact ingest URL.
03
Enable the Create, Acknowledge and Close actions.
CallHeim reads all three, though only Create and Acknowledge change what happens in CallHeim today — see Recovery below for Close.

Example payloadJSON

{
  "action": "Create",
  "alert": {
    "alertId": "a1b2c3",
    "tinyId": "42",
    "alias": "high-cpu-prod",
    "message": "High CPU on prod cluster",
    "description": "CPU > 90% for 10 minutes",
    "priority": "P1",
    "source": "Datadog"
  }
}

Example shape written by us, matching Opsgenie's documented outgoing-webhook payload; check Opsgenie's own documentation for the current fields.

What CallHeim reads from the payload

Payload fields and what each one maps to on the incident
Payload field	Maps to	Note
alert.message / top-level message	incident title
alert.priority (P1–P5)	severity	Maps directly, with P5 clamped to P4 — except a Close action, which always writes P4 regardless of priority.
alert.description / alert.source / integrationName	incident body
alert.alias (or alertId, or tinyId)	identity signal	Opsgenie's own dedup identity, so a follow-up acknowledge or close on the same alias attaches to the existing incident.

How CallHeim processes it

Routing

Each alert source is bound to a service, and the service’s escalation policy (or its team’s) sets who is paged.

Deduplication

Repeats of the same alert collapse onto one incident while they keep arriving within five minutes of each other. A repeat that arrives after a longer quiet gap opens a new incident. Identity is Opsgenie's own alias (its own dedup key), so a create followed by an acknowledge or a close on the same alias collapses onto one incident.

Recovery

A close action does not close the incident automatically. CallHeim lowers the severity it records to P4 when the action is Close, but the literal value Opsgenie sends is "Close" — not the exact string CallHeim's generic close detector matches — so the incident itself stays open until a person resolves it in CallHeim.

Troubleshooting

Common problems and how to fix them
Problem	Fix
A closed Opsgenie alert stays open in CallHeim.	Expected — see Recovery above. Resolve it by hand, or treat the P4 downgrade as your signal to do so.
No alerts arrive.	The integration is created but not turned on — Opsgenie webhook integrations need an explicit "Turn on integration" step after saving.
Acknowledges do not attach to the original alert.	Confirm alias is populated and identical between the create and the acknowledge — a source that generates a new alias per event breaks the link.
HTTP 400 on send.	Check the Description and Details checkboxes are enabled in the integration if you rely on alert.description reaching CallHeim — by default those fields may be omitted or truncated.
HTTP 401 once you enabled signing.	Opsgenie's webhook integration supports custom headers, so add X-ItOnCall-Signature there if you enable signing; confirm the shared secret matches on both sides.

Security

CallHeim verifies an HMAC-SHA256 signature on each source’s requests once you enable signing on that integration (the sending tool must be able to sign). Opsgenie's outgoing webhook integration supports custom headers, so you can add X-ItOnCall-Signature there if you enable signing. Until you do, the ingest URL itself is the credential.

Migration notes

Run in parallel during a move: CallHeim receives PagerDuty Events API v1 and v2 bodies, Opsgenie outgoing webhooks, and alerts forwarded from Splunk On-Call, Squadcast, Zenduty and Grafana OnCall. Every sender needs a CallHeim integration URL and key; existing PagerDuty routing keys are not reused. Opsgenie itself is being retired by Atlassian: new sales ended 4 June 2025 and the product will no longer be accessible from 5 April 2027.

Vendor documentation checked

Atlassian: Integrate Opsgenie with Webhook — checked 2026-09-24

The thresholds it passes through

Dedup window: 300s
Flap threshold: 4 transitions / 600s
Title correlation: similarity ≥ 0.6, same source and service
Group window default: 600s

All defaults are published. You can turn title correlation off or change its threshold, and set the window on your own noise rules; the dedup window and the flap settings are fixed. How alerts are processed →

Send Opsgenie alerts to on-call with CallHeim.