New Sentry issues next to your deploys

New error and fatal issues, once.

What does not arrive

Later crashes of the same issue. Only a new issue, once — not once per event.
Warning, info and debug. Only error and fatal.
Issue updates. Only action created.
Anything that is not an issue — including every-occurrence error webhooks.
Issues from other environments, when the alert rule filters to production.

What arrives

issue created at error or fatal → incident markerissue resolved / archived / unresolved → status on that marker. Kind incident.

Field	What it is
`kind`	`incident`
`title`	Issue title, clipped to 120 characters.
`external_id`	Issue id.
`occurred_at`	firstSeen.
`url`	permalink, otherwise web_url, otherwise url.
`meta.culprit`	Culprit, when present.
`meta.level`	`error` or `fatal`
`meta.environment`	Environment, when present.

How it authenticates

A Sentry Internal Integration belongs to the organization, not to a single Sentry project, and carries one webhook URL. Erdi receives issues when a Sentry Alert Rule for that project sends a notification through the integration — not from the Issues → Created webhook hook, which would deliver every project in the org to the same URL. One Erdi project maps to one integration and one alert rule. Two apps need two integrations and two rules. Sentry signs each request with its Client Secret. This is a webhook, not a pull — nothing is polled.

Signature

HMAC-SHA256 of the raw body, hex, header sentry-hook-signature. The key is Sentry's Client Secret.

Set it up under Settings → Webhooks in your project.

Get started with ErdiKnows

Back to erdiknows.com