Sazabi and incident.io: route issues to an alert source, then read incidents

Last verified on Nov 8, 2026.

incident.io is where many teams run the human side of an incident: who is on call, who has been paged, what the timeline says. Sazabi is AI-native observability and security. It works with incident.io in two directions, and they are configured separately.

What Sazabi does with incident.io

Core integration (Sazabi to incident.io). You create an incident.io API key with permission to manage alert sources and alerts and paste it into Sazabi. Sazabi validates the key and discovers your alert sources, so a delivery rule can name one as its destination. As an issue opens, Sazabi triggers an alert on that source. As it closes, the alert resolves. From there the alert is subject to the alerting and escalation you configured in incident.io. incident.io is an incident integration and a shared notification channel, and a rule can add component, owning-team or severity conditions.

MCP connector (incident.io to the agent). The agent connects to incident.io's hosted MCP server at https://mcp.incident.io/mcp over OAuth. With it the agent can browse active and historical incidents, view alert policies and firing alerts, check on-call schedules and escalation paths, and search incident timelines and postmortems.

The connector has constraints the other integrations do not. Your incident.io role must be Responder or higher. An incident.io admin must open the gear menu at the bottom left, choose MCP Server, and add app.sazabi.com to the allowed redirect domains, or authorization fails with a 404. And because incident.io's authorization server does not issue refresh tokens, the connection lasts about 28 days before it needs reconnecting.

Questions it answers

• Which incidents are open now, and which similar ones were handled before?
• What does the postmortem for last month's database incident say?
• Who is on call, and what is the escalation path for this team?
• Which alerts are firing on an alert policy right now?
• Did the alert Sazabi sent for this issue land on the right source?

A worked example: when the MCP connection stops answering

Roughly four weeks after setup, a thread asks about a running incident and the agent cannot reach the tools. The Sazabi docs describe exactly this case. This is how the checks line up.

Symptom     Connection shows "needs attention" under Settings > MCP connectors
Cause       incident.io tokens last about 28 days and are not refreshed
Fix         Reconnect from Settings > MCP connectors
Before you  Confirm app.sazabi.com is still in the incident.io MCP Server
reconnect   allowed redirect domains, or the browser flow returns a 404

The expiry belongs to the connector. The core integration is set up with an API key, not an OAuth approval, and its own troubleshooting entry is about a revoked key or missing alert-source permissions.

If you are building the same pairing in your own tooling, incident.io's alert source documentation explains what the receiving side expects. A custom HTTP alert source maps a payload to a title, a status of either firing or resolved, and optional description, source_url and metadata. A deduplication key path decides which later events belong to the same alert. Sazabi's side is the one-line version of this: a delivery rule opens the alert, and resolving the issue resolves it. Creating alert sources through incident.io's API needs a key with the alert_source.create scope.

How it fits with other integrations

incident.io and PagerDuty are the two incident destinations that also come with an MCP connector. Rootly and Splunk On-Call take issues but give the agent no tools. For team conversation use Slack. The integrations index has the full list, and pricing covers plans.