Sentry Alerts to On-Call

Sentry issue alerts become CallHeim alerts: repeats on the same issue 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 Sentry’s webhook format, built and tested against sample payloads.

How the alert reaches on-call

Step 1An issue alert rule matches in Sentry (for example, "an issue is seen more than N times").
Step 2Sentry POSTs a JSON body describing the issue to your CallHeim ingest URL.
Step 3CallHeim reads the issue's shortId as the identity signal and maps its level to a severity.
Step 4Repeats on the same issue 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 an Internal Integration in Sentry, not a legacy plugin.
Settings > Developer Settings > New Internal Integration. The legacy webhook plugin still works and CallHeim reads its flat payload shape too, but Sentry's own newer integration path is the internal integration.
02
Enable the webhook and point it at your CallHeim ingest URL.
Create the Sentry integration in CallHeim first to get the exact ingest URL, and select the "Issue" resource subscription.
03
Create (or edit) an Issue Alert rule.
Add a "Send a notification via <your integration>" action so the alert condition actually fires the webhook — creating the internal integration alone does not attach it to anything.

Example payloadJSON

{
  "action": "triggered",
  "data": {
    "issue": {
      "id": "1234567890",
      "shortId": "WEB-STORE-42",
      "title": "TypeError: Cannot read properties of undefined",
      "culprit": "checkout(app/cart.js)",
      "level": "error",
      "permalink": "https://sentry.io/organizations/web-store/issues/1234567890/"
    }
  }
}

Example shape written by us, matching Sentry's internal-integration issue alert format; check Sentry's own documentation for the full payload.

What CallHeim reads from the payload

Payload fields and what each one maps to on the incident
Payload field	Maps to	Note
data.issue.title / culprit	incident title
data.issue.level (fatal / error / warning / info / debug)	severity	fatal→P1, error→P2 (also the default), warning→P3, info or debug→P4.
data.issue.culprit / metadata.value / permalink	incident body
data.issue.shortId (or id)	identity signal	The stable per-issue id, not the per-event id — so repeated events on the same issue collapse instead of opening a new incident each time.

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 Sentry's own shortId (or numeric id) for the issue, so repeated events on one issue collapse regardless of how many times the underlying error fires.

Recovery

Sentry recovery events are not recognised. The parser reads the same fields regardless of what triggered the webhook — it does not distinguish a newly-triggered issue from one a person later marked resolved in Sentry, because resolving an issue in Sentry does not by itself post anything back through an Issue Alert rule unless you build a separate rule for it. Treat CallHeim's incident as something a person resolves once the underlying error has actually stopped.

Troubleshooting

Common problems and how to fix them
Problem	Fix
Nothing arrives when an issue fires.	The internal integration exists but no Issue Alert rule references it — add the "Send a notification via" action to a rule (see setup).
Every event on an issue opens a new incident.	Check the events are actually the same issue (same shortId) — a Sentry fingerprint change on the error creates a new issue with a new shortId.
The title is unhelpful ("Sentry issue").	Neither title nor culprit was present in the payload; that usually means the legacy plugin shape was used with a message field instead.
HTTP 401 once you enabled signing.	Sentry's internal integration does not expose a field for a custom outbound header; if yours does not either, leave signing off for this source.
Alerts land at P2 when they should not.	error is also the fallback severity when level is missing or unrecognised — confirm the alert rule is actually populating level.

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). Sentry's internal integration does not offer a field to add a custom outbound header, so it typically cannot send X-ItOnCall-Signature — leave signing off for this source and rely on the ingest URL as the credential.

Vendor documentation checked

Sentry: Webhooks (integration platform) — 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 Sentry alerts to on-call with CallHeim.