CI/CD terms, defined precisely

Active contributor An active contributor is a person who actually triggered CI in a rolling window — the usage-based billing unit CI analytics tools charge by instead of flat seats. CI cost per contributor CI cost per contributor divides CI spend by active contributors, making costs comparable across team sizes — the same basis many CI tools use for their own pricing. CI history window A CI history window is the span of past pipeline data a tool lets you analyze. Why the window size decides which trends you can see — and which you cannot. CI minute rounding CI providers bill each job in whole minutes, rounding partial minutes up — so a 15-second job costs a full minute, and many short jobs quietly multiply the bill. CI/CD observability CI/CD observability makes pipeline behavior measurable. The two approaches — OpenTelemetry instrumentation and read-only provider APIs — and what each can actually see. Cancelled vs failed runs A cancelled CI run is not a failure — it never reached a verdict. Why mixing the two corrupts failure rates, and when cancellations are actually savings. Change failure rate Change failure rate is the share of deployments needing immediate remediation. What the DORA benchmarks now say, and what CI data alone can and cannot tell you. DORA metrics DORA now publishes five software delivery metrics: deployment frequency, change lead time, change fail rate, failed deployment recovery time, and deployment rework rate. Decisive run A decisive run ended in a verdict — success or failure. It is the denominator every TrimCI failure rate divides by, so verdictless runs cannot distort it. Duration percentiles P50 is the pipeline duration half of runs beat; P95 is the tail only 1 in 20 runs exceeds. Why percentiles beat averages and why P95 sets developer experience. Failure fingerprint A failure fingerprint groups CI failures across runs by their error signature, so a recurring problem gets one name and a count — and triage starts from problems, not runs. Flaky test A flaky test passes and fails on the same code without any change. What causes flakiness, how per-test and pipeline-level detection differ, and why retries hide the cost. GitHub Actions billable minute GitHub Actions meters each job separately, rounds partial minutes up, and charges private-repo usage past a monthly included-minutes quota that varies by plan. GitLab compute minute A GitLab compute minute is hosted-runner usage: job duration over 60, times a cost factor set by runner type. Quotas, factors, and why your own runners are exempt. MTTR in CI/CD MTTR in CI/CD is the time from the first failing run to the next passing run on the same pipeline and branch — not the incident-ops MTTR most glossaries describe. Pipeline queue time Pipeline queue time is the wait between triggering a run and its jobs starting on a runner — invisible in duration metrics and the clearest signal of runner capacity. Pipeline success rate There is no universal good CI success rate: main-branch and PR pipelines play different roles, and the denominator you choose changes the number. How to read yours. Retry tax Retry tax is the compute and engineer time spent re-running CI jobs that already ran — the cost of treating "re-run until green" as a fix, measured from pipeline data. Self-hosted runner A self-hosted runner is CI capacity you operate yourself. When it saves money — and the maintenance, security, and idle-capacity costs the per-minute math leaves out. macOS minute multiplier macOS runner time on GitHub Actions costs roughly ten times the Linux rate. Why Apple hardware carries that premium, and how to keep it off your bill.