Decisive run

A decisive run is a CI run that ended with a verdict about the code — success or failure. It is the denominator that keeps failure rates honest: runs with no verdict — skipped and neutral — are excluded, because they carry no information about whether the change actually worked. Cancelled runs are the judgement call: TrimCI counts a cancellation as a failure (a stuck or manually aborted pipeline is still unhealthy CI) and therefore keeps it inside the decisive denominator, which is why every report tells teams that auto-cancel superseded runs to read failure counts as an upper bound.

How it is used

The failure rate over a time window is:

failure rate = failed runs ÷ decisive runs, where decisive runs = failures + successes

Everything without a verdict stays out of the denominator: a skipped run never executed at all, and a neutral one reached no conclusion. Cancellations are the deliberate exception. A run stopped manually, or killed because a newer push superseded it, says nothing about the code, but it is still CI that failed to deliver an answer — see cancelled vs failed runs for why they are different events, and why TrimCI reports a cancellation as an unhealthy outcome rather than silently dropping it.

The arithmetic is worth walking through. Consider one window:

TrimCI counts the cancellations as failures: 40 ÷ 100 = 40%. The other defensible treatment — dropping cancellations from both numerator and denominator — reports 20 ÷ 80 = 25% on the same window. The 15-point gap is the whole of the judgement call: a team that turns on auto-cancel for superseded pushes will see its reported failure rate rise, which is why every TrimCI report labels failure counts and cost as an upper bound for auto-cancelling repos.

Why it matters

A failure rate is only useful if it means the same thing everywhere it appears. Decisive-run denominators make the number comparable across repositories, providers, and time: every rate is built from the same population of runs that actually reached an outcome, so a repository that skips half its workflows cannot look healthier for it. The same discipline applies to the complement, pipeline success rate, and to change failure rate — any rate whose denominator quietly includes verdictless runs is measuring workflow habits, not code health.

TrimCI applies this definition in every failure-rate denominator — the dashboard hero metrics, per-repository and per-provider tables, the per-user breakdowns, and the trend comparisons in PDF reports all divide by decisive runs, failures (cancellations included) plus successes, and each report restates the rule, cancellation caveat included, in its methodology appendix. It is one of the small choices that make CI pipeline failure analysis trustworthy: a rate means the same thing on every surface, and where a judgement call was made, the report says so.