Sazabi and Rootly: send issues to a service, team or escalation policy

Last verified on Nov 8, 2026.

Rootly sits where an alert becomes an on-call page and, often, an incident. Sazabi is AI-native observability and security, and when it opens an issue worth a human's attention, the Rootly integration puts that issue into the same alerting flow your responders already use.

The docs describe one job for this connection: Sazabi sends issues to Rootly and resolves them again. There is no MCP connector that reads your Rootly data.

What Sazabi does with Rootly

Rootly is a shared notification channel in Sazabi. You paste a Rootly API key into the integration, and Sazabi uses it to discover your Rootly services, teams and escalation policies. Those become the choices for a delivery rule.

When you route to Rootly, the docs name four kinds of target: a default destination, a specific service, a team, or an escalation policy. Sazabi triggers a Rootly alert as an issue opens and resolves it as the issue closes. The rule itself works like any other Sazabi destination: it names an event type such as Issue triggered, and can add a component, owning-team or severity condition.

What happens next is Rootly's. In its documentation an alert is its record of something needing attention, and alerts pass through deduplication, grouping and routing to teams, services and escalation policies before the escalation policy pages someone. Statuses run through open, deferred, triggered, acknowledged and resolved.

What it helps with

• Giving each team's issues a Rootly team target, so they page that team's own policy.
• Sending infrastructure issues to a service target while application issues go to another.
• Keeping low-severity issues out of Rootly by matching only the severities you want.
• Letting a resolved Sazabi issue clear its Rootly alert without a manual step.
• Starting with a default destination, then narrowing to services once the routing is proven.

A worked example: three rules, three targets

Suppose one project has these delivery rules. The service, team and policy names are invented.

Rule 1  Issue triggered, severity: critical            -> Rootly escalation policy "Primary On-Call"
Rule 2  Issue triggered, owning team: Data Platform    -> Rootly team "Data Platform"
Rule 3  Issue triggered, component: checkout           -> Rootly service "Checkout"

A critical issue on the checkout component matches rules 1 and 3, so it is routed to Rootly twice: once to the escalation policy and once to the Checkout service. A rule only adds delivery, so neither route removes the other, and two sets of people may be paged. If that is not what you want, narrow rule 1 or merge the targets.

On the Rootly side, escalation policies are assigned to a team or a service. Rootly's documentation says a policy answers who is notified first, what happens if nobody responds, and how long it keeps escalating. Each level has a paging strategy, and a path is either audible or quiet. So the same Sazabi alert can wake someone or wait in a queue, depending on the policy you target. When a Team is the target, Rootly lets you page all members, only admins, or the team's own policy.

When the issue resolves, the Rootly alert resolves. To check the whole loop, the Sazabi docs suggest triggering a test issue, confirming the alert appears in Rootly, then resolving the issue and confirming it clears.

How it fits with other integrations

Rootly is one of four incident-routing destinations next to PagerDuty, incident.io and Splunk On-Call. Chat teams often add Slack as a second shared destination for the same rule. Browse every method on the integrations index or see pricing.