Pipeline success rate

Pipeline success rate is the share of a pipeline's runs that finish successfully over a time window — and the honest answer to "what is a good one" is that it depends entirely on which pipelines, and which branches, you are counting.

How it is measured

Success rate is successes divided by a denominator, and the denominator is where most published numbers go wrong. Counting every run inflates the total with runs that never rendered a verdict: cancelled runs superseded by a newer push, skipped runs, runs still in progress. A meaningful rate divides by decisive runs — successes plus failures — so that verdictless runs cannot quietly move the number. Cancellations are the one judgement call: TrimCI counts them on the failure side, which is why its failure counts read as an upper bound for repositories that auto-cancel superseded pushes; dropping them from both sides is the other defensible choice. Two teams reporting "94%" with different denominators are not reporting the same thing.

What counts as good

There is no defensible universal benchmark, because the two main pipeline populations exist for opposite reasons:

• Main-branch pipelines run after review and a passing pre-merge check, so failures there should be rare events treated as incidents — this is the population behind change failure rate, and a sagging main-branch rate is a real alarm.
• Pull-request pipelines exist to catch bad changes before merge. A lower success rate there is partly the pipeline doing its job; pushing it toward 100% mostly measures how much validation developers ran locally first.

What is never healthy, on either population, is the same commit failing and then passing on re-run — that is flaky behavior, not signal. The most useful comparison is not against an industry number but against your own baseline: a rate that drifts down over weeks means something changed, whatever the absolute level.

Why it matters

A single blended success rate hides exactly the problems it is supposed to reveal. Averaging post-merge pipelines with PR checks, scheduled jobs, and deploys produces a number nobody can act on, and chasing it produces bad incentives — retry-until-green habits that show up later as retry tax, or pressure to thin out checks. Segmenting by branch role, then tracing what the failures actually are, is the substance of CI pipeline failure analysis, and how fast main comes back after a real failure is its own metric, MTTR.

TrimCI computes every failure rate over decisive runs — the same denominator across the dashboard hero, per-repository tables, and PDF reports — and its reports add a branch-health section that splits main-branch runs from every other branch, so a blended headline rate is never the only number you get.