# Turn critical SonarCloud findings into tracked Jira tickets > Only blocker and critical bugs and vulnerabilities become Jira tickets, with the file, the rule, why it matters, and a suggested fix. - Workflow type: agent - Services: SonarCloud, Jira, Slack Bot - Categories: Engineering - Published: 2026-08-09 ## What it does - Watches your SonarCloud organization and picks up every new issue the moment it is raised, so findings stop piling up in a dashboard nobody opens. - Reads the full finding plus the underlying rule, then judges whether it is worth an engineer's time. Only blocker and critical bugs and security vulnerabilities get escalated, so low value code smells never reach your board. - Checks your engineering project first so the same finding is never filed twice, even though an unfixed issue reappears on every single analysis run. - Opens a Jira ticket with the file, the line, the rule, a plain language explanation of why it matters, and a suggested fix, then posts a short note to your team channel linking both the ticket and the original finding. ## What you'll need - A SonarCloud account with access to the organization you want to watch - A Jira account with permission to create issues, plus the project where engineering bugs live - A Slack workspace and the channel where your team wants the heads up - A rough idea of who owns which part of the codebase, so routing by code author is useful to you ## Prompt When a new issue is raised in my SonarCloud organization, I want it triaged automatically instead of piling up in the Sonar UI where nobody looks. Use the SonarCloud poll trigger for a new issue in the organization so this runs on each fresh finding rather than on a schedule. First, use SonarCloud "Issues — Search" to pull the full context for the finding: the issue key, the rule key, the severity, the issue type, the project and component it belongs to, the file path, the line number, the issue message, and the code author. Then use SonarCloud "Rules — Show" with that rule key to fetch the rule name, the rule description, and the remediation guidance Sonar publishes for it. Now judge whether the finding deserves a ticket. Only escalate issues that are BLOCKER or CRITICAL severity AND that are bugs or vulnerabilities. Skip code smells entirely, and skip anything at MAJOR, MINOR or INFO severity. Most findings should end here with no ticket and no Slack message. That restraint is the whole point: the backlog only stays credible if it holds genuine problems, and teams routinely drown in low severity code smells while real blockers sit unnoticed. If the finding does not clear the bar, stop the run quietly. Before creating anything, use Jira "Search Issues (JQL)" to check whether this finding has already been filed. Search my engineering project for the SonarCloud issue key in the ticket text, for example: project = ENG AND text ~ "". This step is essential because a single unfixed SonarCloud issue reappears on every analysis run, so without it the same finding would be filed again and again. If a matching ticket already exists, stop and do not create a duplicate. If nothing matches, use Jira "Create Issue" to open a Bug in my engineering project. Put the rule name and the offending file in the summary. In the description include: the file path, the line number, the rule name and rule key, the severity and issue type, the component, the code author who last touched that file, a plain language explanation of why this matters (write it from the rule description rather than pasting the raw text), a suggested fix based on the remediation guidance, and the SonarCloud issue key so later runs can dedupe against it. Call out the component and the code author explicitly so whoever triages the board can route the ticket to the right person. Finally, use Slack Bot "Send a Message" to post a short note to my team channel. Keep it to a couple of lines: the rule name, the severity, the file and line, and links to both the new Jira ticket and the original SonarCloud issue. This is a heads up rather than a full report, since all the detail already lives on the ticket. ## How to customize - Move the escalation bar. Keep it to blocker and critical, widen it to major, or let a specific rule through no matter its severity. - Narrow the watch to a single project or a single repository instead of the whole organization. - Change where things land: a different Jira project or issue type, a different Slack channel, or automatically assigning the ticket to the person who last touched the file. ## FAQ ### Will this create a ticket for every SonarCloud issue? No, and that is the point. Only blocker and critical bugs and security vulnerabilities become tickets. Minor issues and code smells are read, judged, and deliberately skipped, so the board stays something your team actually trusts. ### What stops the same problem being filed over and over? An unfixed SonarCloud issue shows up again on every analysis run, so before creating anything the workflow searches your engineering project for that specific finding. If a ticket already exists it stops there and does nothing. ### Does this work with self-hosted SonarQube? This is built for SonarCloud, the hosted version. If you run SonarQube on your own servers the same shape of workflow is possible, but it would need to connect to your instance rather than the SonarCloud service. ### Will the ticket tell an engineer enough to actually fix it? Yes. Alongside the file path and line number it includes the rule name, a plain language explanation of why the finding matters, and a suggested fix drawn from the official remediation guidance, so nobody has to go digging through the Sonar interface. ### How does it know who to route the ticket to? Every finding carries the component it belongs to and the code author who last touched that file. Both go on the ticket, so whoever runs triage can route it to the right person without hunting through the commit history. Use this prompt in General Input: https://www.generalinput.com/prompts/turn-critical-sonarcloud-findings-into-tracked-jira-tickets