New Relic Alerts to On-Call

New Relic alerts become CallHeim alerts: repeats of the same incident collapse onto one CallHeim incident, and the service the integration is bound to pages whoever is on call for it. CallHeim includes a payload mapping for New Relic’s webhook format, built and tested against sample payloads. New Relic ships two alerting shapes — classic Alerts and the newer Workflows — and CallHeim reads both.

How the alert reaches on-call

Step 1A New Relic alert condition (classic) or a Workflow (current) opens an issue.
Step 2New Relic POSTs a JSON body to your CallHeim ingest URL through a webhook destination.
Step 3CallHeim reads the incident or issue id as the identity signal and maps severity or priority to CallHeim's scale.
Step 4Repeats of the same incident 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
Create a Webhook destination in Alerts > Destinations.
Create the New Relic integration in CallHeim first to get the exact ingest URL, and paste it into the destination.
02
Set the authentication, if any.
New Relic's webhook destination offers Basic Auth or a bearer token — not an arbitrary named header, so HMAC signing to CallHeim's exact header is usually not available here.
03
Create (or edit) a Workflow that uses the destination.
Filter the workflow by the policy or tag you want paged, and attach the webhook destination as its channel.

Example payloadJSON

{
  "incident_id": 987654,
  "condition_name": "Apdex < 0.7 on web-store",
  "details": "Apdex score dropped to 0.55 over 5 minutes",
  "severity": "CRITICAL",
  "current_state": "open",
  "policy_name": "web-store-prod",
  "incident_url": "https://alerts.newrelic.com/accounts/1/incidents/987654"
}

Example shape written by us, matching New Relic's classic Alerts webhook format; check New Relic's own documentation for the Workflows payload if you use that shape instead.

What CallHeim reads from the payload

Payload fields and what each one maps to on the incident
Payload field	Maps to	Note
title (Workflows) / condition_name / policy_name	incident title
priority (Workflows: CRITICAL/HIGH/MEDIUM/LOW) or severity (classic: CRITICAL/WARNING/INFO)	severity	CRITICAL→P1, HIGH→P2, WARNING or MEDIUM→P3, INFO or LOW→P4.
details / issuePageUrl / incident_url / description	incident body
issueId (Workflows) or incident_id (classic)	identity signal	current_state is not read, so a close event does not change the identity.

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 New Relic's own issueId or incident_id, so the same open issue re-notifying collapses.

Recovery

New Relic recovery events are largely not recognised, with one narrow exception on paper. A classic payload's current_state: "closed" field is not one CallHeim's generic close detector reads, so it has no effect. A Workflows payload's state field can match — a state value of CLOSED reads as a lowercase "closed", which the detector does recognise — confirm it once in your own workflow before relying on it, and resolve classic-payload incidents by hand.

Troubleshooting

Common problems and how to fix them
Problem	Fix
A closed New Relic incident does not close the CallHeim incident.	Expected on the classic payload — see Recovery above. On a Workflows payload it may already work; verify it once before relying on it.
Severity always lands at P3.	Neither priority nor severity was present in the delivered body — check the destination is attached to a workflow with the right notification template.
HTTP 400 on send.	A custom Handlebars payload template on the destination produced invalid JSON — preview it in New Relic before saving.
No alerts arrive.	Confirm the workflow's filter actually matches the policy or tag the issue was opened under.
HTTP 401 once you enabled signing.	New Relic's webhook destination supports only Basic Auth or a bearer token, not an arbitrary header name — it typically cannot send X-ItOnCall-Signature, so leave signing off.

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). New Relic's webhook destination supports Basic Auth or a bearer token, not a named custom header, so it typically cannot send X-ItOnCall-Signature — leave signing off and rely on the ingest URL as the credential.

Vendor documentation checked

New Relic: Notification integrations (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 New Relic alerts to on-call with CallHeim.