Bitbucket build health console for on-call engineers

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.