Sazabi and Atlassian: file Jira issues, and read Jira, Confluence and Bitbucket

Last verified on Nov 8, 2026.

A ticket is where work gets owned. Sazabi is AI-native observability and security, and its Atlassian support exists so that an investigation ends with a Jira issue the right team already knows how to triage, instead of a message that scrolls away.

The page covers two connections under one Atlassian account: a core Jira integration that files tickets, and an MCP connector that lets the agent read across Atlassian's products.

What Sazabi does with Atlassian

Core integration: Jira. Jira is an issue tracker integration. You authorize through Atlassian OAuth and choose the Jira site if you can reach more than one. During an investigation the agent can create a Jira issue and keep it current: it can update fields, move it through your project's workflow, comment on it, and link it back to the Sazabi issue or thread. The connection acts on behalf of the person who authorized it, and every issue is attributed to that user, which is why the docs recommend a dedicated service account. If a Sazabi issue is linked to a Jira task that syncs status, the task decides when the issue closes.

MCP connector: Atlassian. This connects Atlassian Rovo's hosted MCP server at https://mcp.atlassian.com/v1/mcp using OAuth 2.1 with dynamic client registration. The agent can search and read Jira issues, projects and boards, search and read Confluence pages and spaces, work with Jira Service Management requests and Compass components, and reach Bitbucket repositories and pull requests. Write tools are gated by a per-connection read-only toggle and your organization's tool policy.

What it helps with

• Turning a finished investigation into a Jira issue in the project that owns the service.
• Finding the Confluence runbook that matches a failing component before suggesting a fix.
• Checking a Jira Service Management request or a Compass component for context on an affected service.
• Reading board and issue history to see whether someone is already on a problem.
• Keeping a ticket's status and comments in step as the investigation moves.

A worked example: a ticket filed under a service account

A platform team creates a Jira user named sazabi-bot and authorizes the Jira connection with it. Later, a thread ends with a request to file the work. The names are invented.

Thread: payments-api latency
You     File this as a Jira issue in OPS and link back to this thread.
Agent   Created OPS-214 "payments-api p99 spike after cache config change"
        Reporter: sazabi-bot    Status: To Do
        Comment: findings and a link to the Sazabi thread
You     The fix merged. Move it to In Review.
Agent   Transitioned OPS-214 to In Review.

Each step lines up with Atlassian's tools. On the Atlassian MCP server, creating and editing work items sit in a write permission group requiring the write:jira:agent-interface scope, with tools like createJiraIssue, editJiraIssue, transitionJiraIssue and addOrEditJiraIssueComment. Atlassian's page also says every tool call needs a cloudId, which getAccessibleAtlassianResources returns, so the site you pick at authorization matters. Underneath, Jira's REST API v3 issues resource is where create, edit and transition operations live.

Because Jira attributes writes to the authorizing user, sazabi-bot appears as the reporter and not a teammate. If that account later loses access, the docs say to restore its permissions in Atlassian and choose Check connection in Sazabi. If authorization expired, disconnect, add the connection again, and select the same site and project settings. Adding a connection alone does not repair an existing multi-site one.

How it fits with other integrations

One tracker per team is typical, so Jira is the alternative to Linear. Code context comes from Bitbucket or GitHub, and Atlassian's connector can also reach Bitbucket pull requests. Issue alerts can reach people through Slack. Browse all integrations or check pricing.