# Turn failed Bitbucket builds into Jira bugs > The moment a Bitbucket pipeline fails, we read the build log, diagnose the likely cause, and open (or comment on) a Jira ticket the on-call engineer can pick up. - Workflow type: agent - Services: Bitbucket, Jira - Categories: Engineering - Published: 2026-07-17 ## What it does - Watches every Bitbucket Pipelines run and springs into action the moment one comes back failed. - Pulls the run, finds the step that broke, and reads the tail of the build log around the failure marker. - Writes a plain-English diagnosis of the likely root cause (compile error, flaky test, missing env var, dependency issue) with the offending stack trace, commit hash, branch, and a direct link back to the pipeline. - Deduplicates against Jira first: if the same root cause has been filed in the last 24 hours, we comment on that ticket instead of opening a new one. ## What you'll need - A Bitbucket workspace with Pipelines enabled and permission to read build logs. - A Jira project (usually your engineering or platform project) where new bug tickets should land. - A rough idea of your team's bug conventions (issue type, labels, priority) so tickets look like the ones you already file. ## Prompt When a Bitbucket Pipelines run finishes with a FAILED state, triage the failure and open a Jira bug so the on-call engineer has something actionable to pick up. The trigger is an incoming Bitbucket webhook subscribed to pipeline events. Ignore any event where the run's result state is not FAILED (skip SUCCESSFUL, STOPPED, and in-progress states). Once a failed run comes in, gather context from Bitbucket. Call Get Pipeline to confirm the current state and pull the commit hash, branch, author, and pipeline URL. Then call List Pipeline Steps for that run and identify the first step whose result is FAILED — that is the step that actually broke. Read the raw build log for that step with Get Pipeline Step Log; the log is text/plain and can be very large, so quote only the last 40 to 80 lines around the failure marker (look for things like 'FAILED', 'Error:', 'Traceback', 'exit code', or the runner's failure banner) rather than dumping the whole log into Jira. From that log excerpt, diagnose the likely root cause in plain English. Classify it into one of: compile error, failing test (call out flaky-looking ones), missing or misconfigured environment variable, dependency install or resolution issue, infrastructure or timeout, or 'other'. Extract the most useful signal — the failing test name, the exception class and message, the offending shell command, or the missing variable name — so it can be searched against later. Before creating anything, dedupe against Jira. Use Search Issues (JQL) with a query like project = AND issuetype = Bug AND created >= -24h AND (summary ~ "" OR description ~ "") — the key signal being the failing test name, exception class, or command that broke. If a matching ticket exists, use Add Comment to append a note on that existing issue instead of opening a duplicate. The comment body must be Atlassian Document Format (ADF), not raw markdown; include the new pipeline URL, commit, branch, and a short 'happened again' line. If no matching ticket exists, call Create Issue in the engineering project with issuetype = Bug. The summary should be a punchy one-liner naming the failure ('Pipeline failing on main: NullPointerException in UserServiceTest.testLogin'). The description (ADF) should contain: a one-paragraph plain-English summary of what likely broke and why, the offending stack trace or command in a code block, a facts section with the commit hash, branch, author, and failing step name, and a direct link back to the pipeline run in Bitbucket. Match the team's usual labels and priority conventions if they've been configured; otherwise leave those fields alone. Behavioral rules: never file a ticket for a SUCCESSFUL or STOPPED run; never dump the entire raw log into a Jira ticket — quote only the relevant tail; always prefer commenting on an existing 24h-old ticket over creating a near-duplicate; and treat the commit hash + failing step + exception signature as the identity of a 'root cause' when deciding whether two failures match. ## How to customize - Pick which repositories to watch — everything in the workspace, or a specific set. - Change the Jira project key and default fields like issue type, labels, priority, or assignee. - Adjust the dedupe window (24 hours by default) or how much of the build log gets quoted into the ticket. ## FAQ ### What kinds of failures does this catch? Any pipeline run that finishes in a failed state — compile errors, failing tests, missing environment variables, dependency install problems, and timeouts. The agent reads the log and describes what actually broke in plain language. ### Won't this spam Jira when the same build keeps failing? No. Before opening a ticket, we search Jira for an existing bug with the same root cause in the last 24 hours. If we find one, we add a comment to it instead of creating a duplicate, so the engineer sees one growing thread rather than a wall of near-identical tickets. ### Does the ticket include enough context to actually debug? Yes. The summary explains the likely cause, and the description includes the offending stack trace or command, the commit hash and branch that broke, and a direct link back to the pipeline run in Bitbucket. ### Can I control which Jira project the bugs go into? Yes. You pick the project key when you set up the workflow. Most teams point it at their engineering or platform project and set a default issue type of Bug. ### Does this fire for pipelines that were manually stopped? By default we only file tickets for genuine failures, not runs a person cancelled. If you want stopped runs tracked too, you can widen the filter when you set the workflow up. Use this prompt in General Input: https://www.generalinput.com/prompts/turn-failed-bitbucket-builds-into-jira-bugs