Pipeline performance

Build durations, success and failure rates, MTTR, recent workflow runs, and where self-healed runs show up.

The Pipeline Performance page tracks how healthy and how fast your workflows are.

There are two ways to use it. As a monitor, you glance at the overview and trends to answer "is CI getting better or worse?" As an investigation tool, you filter down to one repository or workflow and use the runs table and recovery metrics to answer "what exactly happened, and how did we handle it?" The sections below are laid out roughly in that order.

Performance Overview#

• Workflow Health: overall success rate as a gauge.
• Average Build Duration, Successful Builds, and Failed Builds for the selected window.
• Top Failed Builds: the three repositories and the three workflows with the most failed builds. Every entry links straight to the repository or the workflow file on GitHub, so you can jump from the hotspot to the fix.
• Repositories Monitored and Workflows Monitored counts, confirming exactly what the numbers cover.

Guidance for reading the gauge: a single bad day rarely means much; one broken merge can sink a day's success rate on its own. What deserves attention is a sustained drop across the window, or a gap between repositories: if one repo's health sits far below the rest, Top Failed Builds will usually name the workflow responsible, and its deep-link takes you straight to the workflow file on GitHub.

Build Trends#

• Successful Builds Over Time by Repository: the daily trend of successful builds, one line per repository.
• Average Build Duration by Repository and Workflow Duration: bar charts ranking repositories and workflows by average duration, each with a Top 5 / Bottom 5 dropdown. Chart labels link to the repository or the workflow file on GitHub.
• Build Duration Trend Across Workflows to spot pipelines that are getting slower.

Duration trends come in two shapes worth telling apart. A step change (duration jumps on a specific day and stays there) almost always traces back to a concrete edit: a new step, a dependency change, a different runner. A slow creep is the quieter problem: growing test suites and accumulating steps that nobody notices week to week. The trend charts exist to make the creep visible. Note that the AI agent also watches for this: a run taking far longer than the recent average is one of the events that triggers an analysis on Optimization Insights.

Recent Workflow Runs#

The Workflow Runs table is a single feed of individual runs across all your repositories: status icon, timestamp, repository, workflow, branch, and duration. Every column sorts, the default order is most recent first, and runs paginate at 13 per page. Clicking a row opens the run on GitHub.

When Latchkey's self-heal repairs a run, the table shows a green Healed badge in the Heal column. Click it to open the Heal Details drawer on the Runners page: what failed, the diagnosis, and the exact action taken in plain language; for AI-diagnosed failures it also includes the agent's iterations. That matters when reading this page because a healed run counts as a rescue, not a clean pass: if the same workflow keeps needing heals, the underlying flakiness is still there to fix. See Self-healing for how healing works and the Runners page for the full Recent Heals feed.

Recovery & Comparative Analysis#

• Build Fail Rate and Rebuild Success Rate: how often builds fail, and how often a re-run goes green.
• Mean Time to Recovery (MTTR) and MTTR Over Time: the average time between a failed build and the next successful build, paired with its daily trend.
• Build Status by Repository: successful, failed, and cancelled builds per repository in a stacked bar chart, with a Top 5 / Bottom 5 dropdown.

What each recovery metric tells you#

MTTR is the average time between a failed build and the next successful build. It measures your team's whole recovery loop: noticing the red build, diagnosing it, and landing the fix. There is no universal "good" number; a team deploying many times a day needs MTTR measured in minutes, while a weekly-release team can tolerate hours. What is universally bad is a rising MTTR Over Time trend: it means failures are getting harder to diagnose, or the team is getting slower to respond, and either one compounds.

Rebuild Success Rate is the flakiness detector. It tells you what fraction of failures disappear when you simply run the build again, and the two extremes point at very different problems:

Build Fail Rate only becomes meaningful next to rebuild success rate. A 10% fail rate made of real regressions and a 10% fail rate made of flaky re-run-and-forget failures are entirely different problems, and this page gives you both numbers precisely so you can tell them apart.

Metric glossary#