Sazabi and PagerDuty: route issues to services and read on-call context

Last verified on Nov 8, 2026.

Paging is the point where an observability finding turns into a person's night. Sazabi is AI-native observability and security, and its PagerDuty integration covers both sides of that moment: sending the issue to whoever is on call, and letting the agent read PagerDuty when it needs to understand who was paged and why.

These are two separate connections. Connecting one does not enable the other.

What Sazabi does with PagerDuty

Core integration (Sazabi to PagerDuty). You give Sazabi a PagerDuty REST API token. Sazabi uses it to discover your PagerDuty services, so a delivery rule can point at a specific one. When an issue opens, Sazabi triggers an alert on that service. When the issue closes, the alert resolves. The docs also say Sazabi can acknowledge an alert and escalate it along your PagerDuty escalation policy. PagerDuty is an incident integration and a shared notification channel, so routing is decided by delivery rules, each of which can match on component, owning team or severity.

MCP connector (PagerDuty to the agent). This is read-only. You create a key in PagerDuty under Integrations > API Access Keys with Read-only API Key ticked, pick your US or Europe region, and the agent gets PagerDuty's hosted MCP tools. It can read incidents with their alerts, notes, log entries and change events. It can look up who is on call, schedules and escalation policies for a service, review services, teams and business service dependencies, and pull incident metrics such as time to acknowledge and time to resolve.

Questions it answers

• Who is on call for this service right now, and what is its escalation policy?
• Which PagerDuty incidents came from Sazabi issues this week, and how long did each take to acknowledge?
• What change events were recorded on this service before the page?
• Which services does a business service depend on?
• Is a severity-gated rule keeping low-priority issues off the pager?

A worked example: one issue, one alert, one lookup

A rule sends Issue triggered for high and critical issues on the payments component to the PagerDuty service Payments API. Here is the lifecycle, with made-up names.

Sazabi issue   Payment confirmations failing in payments-api     severity: critical
  -> PagerDuty alert triggered on service "Payments API"
  -> incident assigned to the on-call responder

Thread, later:
  You     Who was paged for the payments-api issue, and did anything change on that service first?
  Agent   (reads the PagerDuty incident, its change events and the escalation policy through the read-only connector)

Behind the PagerDuty side sits PagerDuty's own model. In its Events API documentation, an alert event is routed to a service and creates an incident assigned to the person on call. Follow-up events acknowledge or resolve that alert. A change event is different: it records something like a merged pull request, shows up in the service's activity stream, and does not notify anyone. Sazabi's connector lists change events among the things the agent reads, so the agent can read them next to the incident.

Closing the issue in Sazabi resolves the alert. If nothing arrives on the service, the docs point to two checks: the delivery rule must name both the event type and the PagerDuty destination, and no severity or component condition may exclude the issue.

How it fits with other integrations

PagerDuty sits in the same incident-routing group as Rootly, incident.io and Splunk On-Call, and a team usually picks one. Chat destinations like Slack can run beside it. Sazabi can also open a ticket in Linear. Compare options on the integrations index or review pricing.