# Bitbucket build health console for on-call engineers

> See every repository's build health on one screen, open the failing step, and re-run or stop a build without leaving the page.

- Workflow type: app
- Services: Bitbucket
- Categories: Engineering
- Published: 2026-08-14

## What it does

- One live screen covering every repository in your workspace: builds in the last 24 hours, success rate, typical build time, and a leaderboard of the repos failing most often.
- A table of recent builds that opens on failures and in-progress runs first, so you see what needs attention instead of hunting repo by repo.
- Click any build to see its steps and the raw output of the one that broke, plus an Explain this failure button that reads the log and gives you the likely cause in plain language.
- Re-run a build against the same branch or commit, or stop one that is stuck, straight from the detail view.
- Branches that have failed three or more times in a row get flagged as a likely flaky build, so nobody keeps re-running something that will never pass.

## What you'll need

- A Bitbucket Cloud account with access to the workspace you want to watch
- Bitbucket Pipelines switched on for the repositories you care about
- Permission to run and stop builds, if you want the re-run and stop buttons to work

## Prompt

Build me a build health console for Bitbucket Pipelines that our on-call engineer can keep open all day. Right now, finding out what is broken means opening each repository separately in Bitbucket, so I want one screen that covers the whole workspace and lets me act on a broken build without leaving it.

The top of the app is a health strip across every repository. Use List Repositories in Workspace to enumerate the repos I can access, then List Pipelines per repo to pull recent runs. For each repository show the number of runs in the last 24 hours, the success rate over that window, and the median run duration. Next to the strip, show a leaderboard of the repositories failing most often in the window, worst first. Let me pick the workspace once and remember it, and let me widen the window (for example to 7 days) from a control on the page.

Below the health strip is a table of recent runs across all repositories, newest first. Columns: repository, branch or tag, commit (short hash and message if available), who or what triggered it, state, result, start time, and duration. Default the table filter to failed and in-progress runs only, since that is what the on-call engineer actually cares about, with a toggle to show all runs. Let me also filter by repository and by branch. Bitbucket pipeline states and results are uppercase (states like PENDING, IN_PROGRESS, COMPLETED and results like SUCCESSFUL, FAILED, ERROR, STOPPED), so match on the uppercase values and render friendly labels with a colour per result.

Clicking a row drills into a run detail view. Call Get Pipeline for the run's current state and result, List Pipeline Steps for the ordered steps, and then Get Pipeline Step Log for the first step that failed to show its raw output. The log comes back as plain text, so render it in a scrollable monospace pane scrolled to the end by default, with a copy button and the ability to open the log of any other step in the run, not just the failing one.

In the detail view include an Explain this failure button that hands the failing step's log to a background agent. The agent reads the log and writes a short plain-language summary of the likely cause plus a suggested next step, for example a dependency that could not be resolved, a test that timed out, or a missing environment variable. Show the explanation inline under the log and store it against that run so re-opening the run shows the saved explanation instead of paying for a fresh read, with a button to regenerate it on demand.

From the detail view I need two actions. Trigger Pipeline re-runs the build against the same branch or the same commit as the run I am looking at, letting me choose which of the two. Stop Pipeline kills a run that is stuck and still in progress, so only enable that button while the run is actually running. Confirm before either action, then refresh that run's state so I can see the result of what I just did.

Flaky build detection matters here. Look at the run history per repository and branch, and whenever a branch has three or more consecutive failed runs, mark it as a likely flaky build. Show the flag as a badge in the runs table and at the top of the detail view, and when I click re-run on a branch carrying that badge, warn me before it fires so we stop re-running blindly. Make the threshold easy to change in one place.

Two implementation notes. The Bitbucket Pipelines endpoints have separate and lower rate limits than the rest of the Bitbucket API, so the handlers should batch reads, fetch the cross-repo health data in one pass and cache it rather than refetching per card, and never pull logs on render: fetch a step log only when a run is opened, and cache it per step for the session. Also, the pipeline paths require a trailing slash, so keep that in the handler URLs.

Give the console a manual refresh button plus a gentle auto-refresh (roughly a minute) that respects those rate limits, and show when the data was last updated. Remember each user's workspace choice and table filters between visits, and keep the whole thing dense enough that the health strip and the runs table are visible together on one screen.

## How to customize

- Change what the table shows by default, for example everything instead of just failures and in-progress runs, or only the handful of repositories your team owns
- Widen or narrow the health window from the last 24 hours to the last few days
- Move the flaky threshold up or down from three failures in a row to whatever your team treats as noise

## FAQ

### Does this change anything in my Bitbucket account?

Almost everything it does is read-only. The only two buttons that act are re-run and stop, and both ask you to confirm first.

### Does it cover all of my repositories?

Yes. It lists every repository you can see in the workspace and surfaces the ones with recent build activity, so you no longer open each repository separately to find out what is broken.

### What does the flaky label actually mean?

A branch is marked as a likely flaky build once it has failed three or more times in a row. It is a hint to investigate rather than re-run blindly, not a verdict, and you can still re-run it if you want to.

### Does the failure explanation read my code?

No. It reads the build output of the step that failed and summarizes the likely cause in plain language, the same way a teammate would skim the log for you.

### Can the whole team keep it open at once?

Yes. Each person opens it with their own Bitbucket connection, and their filter choices are remembered separately.

Use this prompt in General Input: https://www.generalinput.com/prompts/bitbucket-build-health-console-for-on-call-engineers