Use Sentry Issues and Errors with Sazabi

Last verified on Nov 8, 2026.

Sentry groups errors into issues and records what people did with them: someone resolved one, someone commented, an alert rule fired. Those are decisions and signals about your system, and they are worth reading next to the logs that were written at the same moment.

Sazabi, the AI-native observability and security platform, takes Sentry in three forms. Issue-level events come through an Internal Integration. Individual errors come through the Sentry SDK pointed at a Sazabi DSN. The agent can also browse Sentry directly.

What each source sends

Issue, comment and alert webhooks. Sazabi can create a Sentry Internal Integration for you, or you can create it yourself and paste in the intake URL. Either way, issue and comment webhooks stream in, and alert events arrive for each Issue Alert or Metric Alert rule you add the integration to. Sazabi's docs are explicit that this carries events about issues, not each error occurrence. Creating the integration needs the org:write scope, which only Owners and Managers have.

Sentry's issue webhook has an action of created, resolved, assigned, archived or unresolved, plus status, a substatus such as regressed or escalating, and statusDetails that can include inRelease.

SDK errors and logs. Point a Sentry SDK at https://sazabi@your-intake-host/0. Errors, exceptions, structured logs and other envelope telemetry arrive, along with transactions and standalone spans. You can replace the Sentry DSN or use the SDK's makeMultiplexedTransport to send to both, which leaves your Sentry project untouched.

Agent connectors. The MCP connector reaches Sentry's hosted server and lets the agent search issues and error events, read stack traces and breadcrumbs, and walk organizations, teams and projects. The sentry-cli sandbox connection uses SENTRY_AUTH_TOKEN, and optionally SENTRY_ORG.

Questions it answers

Which issues were marked resolved this week, and do the same errors still show up in our logs?
What were the stack trace and breadcrumbs for the issue assigned to me?
Did an alert rule fire before or after the deploy?
Which services logged errors in the minutes around a Sentry issue being created?
Who commented on this issue, and what did they find?

A worked example: a resolved issue that regressed

A teammate marks an issue resolved inRelease latest. Two days later Sentry reopens it. The webhook arrives as an unresolved action with a regressed substatus. A trimmed record, with fictional values:

{
  "action": "unresolved",
  "data": {
    "issue": {
      "status": "unresolved",
      "substatus": "regressed",
      "project": { "slug": "orders-api" },
      "platform": "python"
    }
  },
  "actor": { "type": "application", "name": "Sentry" }
}

The actor shows Sentry did this, not a person. Ask the agent:

A Sentry issue in orders-api was reopened as regressed today. Show the Sentry
issue events from the last 48 hours, then the orders-api error logs since the
resolve. Is the error back, or did something else change?

The issue events give the timeline of resolve and reopen. The SDK errors and service logs, if you also forward them, show whether the exception text matches. With the MCP connector the agent can also open the issue's stack trace and breadcrumbs, so the comparison is between the old trace and the new one, not between memory and a log line.

How it fits with other integrations

Sentry is in observability tools, where PostHog covers product events. Sentry SDK transport is HTTP envelopes, while the OpenTelemetry page covers OTLP for everything else. Support reports from Plain can sit beside the same errors. See pricing for how volume counts.

Ways to connect

Sentry (MCP connector): Give the Sazabi agent tools to browse error events, issues, and project data across your Sentry organizations.

Log sources

Sentry (native log source, observability tools): Connect your Sentry organization so Sazabi can create an Internal Integration that streams issue, comment, and alert events in real time.
Sentry (manual log source, observability tools): Create a Sentry Internal Integration pointed at your Sazabi intake URL to stream Sentry issue, comment, and alert events into Sazabi.
Sentry SDK (manual log source, sdks): Point your Sentry SDK at a Sazabi DSN to forward errors, structured logs, and envelope telemetry — either replacing your Sentry project DSN or sending to both.

What Sazabi detects from these logs today

These detections are on for every production project, with no monitors or alert rules to write. Sazabi opens an issue when one fires.

Novel event: A kind of error that has never appeared before.
Client errors: JavaScript exceptions, failed fetches and hydration errors.

Frequently Asked Questions

Does the Sentry integration send every error occurrence?

No. The Internal Integration sends events about Sentry issues, such as created, resolved or commented on. For individual errors and stack traces, use the Sentry SDK setup with a Sazabi DSN. You can set up both.

Can I keep sending errors to Sentry too?

Yes. The SDK source supports a multiplexed transport that sends to both your existing Sentry project and Sazabi. With Python, sending to both copies only error events to Sazabi.

Who can create the Internal Integration?

It requires the org:write scope, which Sentry grants only to organization Owners and Managers. On the manual path no auth token leaves Sentry. On the connected-account path you supply a User Auth Token.

Why do I see issue events but no alert events?

Alert delivery is opt-in per rule. Add the integration as a notification destination on each Issue Alert or Metric Alert rule to receive event_alert and metric_alert webhooks.

Sources

Connect Sentry to Sazabi