Sentry integration

Page your on-call engineer from Sentry alerts

Send Sentry alert notifications to Oncallz and new or regressed errors page whoever is on call. Oncallz reads Sentry's legacy webhook payload directly; payloads from Sentry's newer internal integrations arrive with a generic title and need a little extra care.

Start free All integrations

Set up Sentry → Oncallz in a few minutes

1 In Oncallz, open Integrations, pick the team, name the integration "Sentry" and click Create. Use "Group by ID" for the legacy webhook and "Always create new" for an internal integration (see below).
2 Copy the Inbound URL of the new integration.
3 If your project still offers the legacy WebHooks integration (Project Settings → Legacy Integrations → WebHooks), enable it and paste the Oncallz URL into Callback URLs.
4 Otherwise create an internal integration in your organisation settings, paste the Oncallz URL as its webhook URL and enable it as an alert rule action.
5 In the Sentry alert rules that should page, add the action that sends a notification through the webhook or the internal integration, then trigger a test.

Legacy webhook fields Oncallz uses

{
  "id": "4521778301",
  "project": "checkout-api",
  "level": "error",
  "culprit": "app/payments/charge.py in capture",
  "message": "TimeoutError: upstream did not respond",
  "url": "https://sentry.io/organizations/acme/issues/4521778301/",
  "triggering_rules": ["Page on new errors"],
  "event": { ... }
}

id (the Sentry issue) groups repeats into one incident, message becomes the title and level sets the severity. Sentry describes the legacy webhook as deprecated and steers new setups to internal integrations (September 2026).

How is severity set?

From the legacy payload's level. error and warning map directly, info stays info, debug becomes info and fatal becomes error. Internal-integration payloads nest the level inside data.event, which Oncallz does not read, so those incidents are paged as critical unless you set the severity another way.

How are duplicates grouped?

With the legacy webhook and "Group by ID", the Sentry issue id is the dedup key: every alert for the same issue lands on one open incident's timeline and raises its occurrence count, without paging again.

Internal-integration payloads have no top-level id or title, so grouping would fold every Sentry alert into one incident titled "Incident". Use "Always create new" for them.

Does it auto-resolve?

No. The legacy webhook only fires when an alert rule triggers. Internal integrations can send issue "resolved" webhooks, but Sentry puts that in an action field that Oncallz does not interpret, so resolving an issue in Sentry does not resolve the Oncallz incident.

Resolve it in Oncallz once the fix is out.

Making internal integration alerts readable

Sentry's internal-integration payload keeps the title, level and issue id under data.event, so Oncallz titles the incident "Incident" and pages it as critical. The whole payload is still on the incident page, and AI investigation, when enabled, reads it.

You can give these incidents a fixed title and severity by adding them to the URL, for example ?summary=Sentry%20alert&severity=error.

Sentry also documents a one-second response limit for integration webhooks; Oncallz replies after it has opened the incident, which can take longer when AI investigation is on, so Sentry may report timeouts.

Frequently asked questions

Which Sentry webhook works best with Oncallz?

The legacy WebHooks integration, where your project still has it. Its payload has the issue id, the event message and the level at the top level, so Oncallz gets a real title, the right severity and one incident per Sentry issue.

Sentry calls the legacy webhook deprecated, and new setups use internal integrations, which Oncallz receives with a generic title.

Will resolving an issue in Sentry resolve the incident?

No. Sentry reports issue resolution in an action field, and Oncallz only infers resolve from status, state, trigger or event_action. Resolve the incident in Oncallz from the web app or the iOS app.

The incident keeps the Sentry payload, including the issue link, so the responder can check the issue before closing it.

Should every Sentry error page someone?

Usually not. Sentry alert rules decide what gets sent, so limit paging rules to new issues, regressions or high-frequency errors in production. On the Oncallz side, call suppression rules can skip the phone call for known-noisy titles, and maintenance windows can hold paging during a deploy.

Why is my Sentry incident titled "Incident"?

You are probably using an internal integration. Its payload keeps the title inside data.event, where Oncallz's generic detection does not look. Add summary and severity to the webhook URL as query parameters to set a fixed title, or use the legacy webhook if your project offers it.

The full payload is always on the incident.

Ready when the pager goes off.

Create your workspace in minutes. Free to start, no credit card — $4 per user a month when you’re ready.

Start free