Jira
Issues alongside incidents, and in the Copilot's knowledge.
Delivery → Jira connects issue tracking to the operational side.
Setup
Settings → Datasources → Jira. URL, user, API token. The same credentials serve Confluence.
What it does
| Issues in AccelerUp | Search and read, without leaving |
| Incident linkage | Attach issues to incidents |
| Release linkage | Issues referenced by commits in a release |
| Copilot knowledge | Issues and Confluence pages are readable by the Copilot |
Copilot reads Jira and Confluence
The Copilot has four read tools over Jira and Confluence, and their content is
part of its knowledge base (kinds jira_issue and confluence_page).
This is what lets it answer "has this happened before?" from your own history rather than in general — the answer is usually in a ticket somebody closed eighteen months ago.
Read-only, and it reuses the existing Jira integration credentials — no second set to manage or rotate.
Issues on incidents
Attaching an issue to an incident links them in both directions: the incident shows the issue, and the issue is findable from the incident history.
Do this for follow-up work from post-mortems, so action items live where the team already tracks work rather than in a list only AccelerUp knows about.
What it does not do
Write. AccelerUp does not create or transition Jira issues.
Two-way sync sounds useful and reliably produces a system where neither side is authoritative and both are slightly wrong.
Where this behaviour lives: backend/internal/integration/jira.go, backend/internal/integration/confluence.go. If the code and this page disagree, the code is right — please fix the page.
Part of Delivery — Deployments, pipelines, releases and everything that ships code.