Michaela
A bug that sits in one tool while the team works in another is a bug nobody sees. The point of an integration is to put the report where developers already look, with the evidence attached, and to keep the status honest.
Three places a report can go
| Destination | Good for |
|---|---|
| The SnagRelay inbox | Teams without a tracker, or who want to triage in one place |
| One tracker per project: Jira Cloud, Linear, GitHub, GitLab.com, Trello or Azure DevOps Services | Teams whose work lives in a tracker |
| Your coding agent, over MCP | Teams that fix bugs with Cursor, Claude Code or Codex |
These are not exclusive. A report in a tracker can still be read by your agent by key.
One-way delivery
A report arrives as a ticket with the element, console errors, requests with bodies and repro steps. Developers work in their tracker as usual. The downside: status changes in the tracker do not flow back, so the report keeps its old status unless someone updates it.
Two-way status sync
On higher plans, status changes in the tracker flow back to SnagRelay. When a developer moves a ticket to done, the report reflects it, without manual bookkeeping. See pricing for which plans include it.
Setting up each tracker
- Jira: Jira Cloud. Authenticate your account and choose the project.
- Linear: authenticate your account and choose the team.
- GitHub: authenticate and choose the repository.
- GitLab: GitLab.com. Choose the project.
- Trello: choose the board and list.
- Azure DevOps: Azure DevOps Services. Choose the project.
The agent as a third consumer
Your tracker holds the ticket; your agent needs the evidence. Over MCP, it reads the report by the ticket key, pulls any request body it needs and resolves the report when the fix lands, which sends the reporter a "fixed" email.
Keep it quiet
Too many tickets teach developers to ignore the tracker. Use report types to separate bugs from questions, keep staging and production in separate projects, and let the inbox hold what is not ready for a ticket yet.