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.
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 ~ "<sonarcloud issue key>". 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.
What does this prompt do?
- 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 do I need to use this?
- 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
How can I customize it?
- 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.
FAQs
Will this create a ticket for every SonarCloud issue?
What stops the same problem being filed over and over?
Does this work with self-hosted SonarQube?
Will the ticket tell an engineer enough to actually fix it?
How does it know who to route the ticket to?
Related templates
When someone leaves, we check which shared passwords they used in their final months and post a ranked rotation list to your security channel.
Every Monday, check every S3 bucket for public exposure, missing encryption and weak backup settings, then get the risks ranked in Slack.
Twice every weekday, the conversations from your social inbox land on the right HubSpot contact timelines, with a Slack recap for sales.
Every morning, find the addresses that hard bounced or filed a spam complaint, update the matching HubSpot contacts, and post a short Slack recap.
Every weekday at 4pm, spot the threads that went quiet, stage a ready-to-send nudge in your mailbox, and get a ranked Slack recap.
When you merge a fix in GitHub, this agent checks the matching dead-letter queue, replays the failed messages, and reports back on the pull request and in Slack.
Stop letting real bugs drown in code smells.
Escalate only the findings that matter, with enough context on the ticket that someone can actually fix them.