Build Success Rate Calculator
Calculate build success rate and Mean Time Between Failures (MTBF) from total builds, successes, and elapsed time.
Inputs
Total number of builds run in the measurement period.
Number of builds that completed successfully.
Total wall-clock time covered by the measurement period.
Build Success Rate
92.00%
Mean Time Between Failures
18.00hr
Total Failed Builds
40builds
Step by step
Success rate = successes ÷ total × 100
460 ÷ 500 × 100
= 92.00%
Failures = total − successes
500 − 460
= 40 failures
MTBF = total time ÷ failures
720hr ÷ 40
= 18.00hr
How it works
Build success rate is the simple percentage of builds that passed out of all builds run, giving a snapshot reliability metric for a pipeline or team over a period. Mean Time Between Failures complements it with a time-based view — total elapsed time divided by the number of failures — which better reflects how often a team actually experiences a broken build in practice, since a low-frequency but high-volume pipeline can have the same success rate as a high-frequency one while producing failures at a very different real-world cadence.
Formulas
Success rate
successRate = (successfulBuilds / totalBuilds) × 100
- S
- Number of successful builds
- N
- Total builds
- r
- Success rate percentage
MTBF
MTBF = totalTime / failures
- T
- Total elapsed time in hours
- F
- Number of failures
- \text{MTBF}
- Mean time between failures in hours
Frequently Asked Questions
Why track both success rate and MTBF instead of just one?
Success rate is volume-normalized and ignores build frequency, while MTBF is time-normalized and ignores how many builds ran — a pipeline running 10x more builds per day at the same success rate has a proportionally shorter MTBF, which is often the more actionable signal for on-call/interrupt burden.
What's considered a healthy build success rate?
Mature CI pipelines with good test isolation typically target 90%+ on main-branch builds; consistently lower rates often point to flaky tests, unstable infrastructure, or a broken-build culture where failures aren't fixed before more commits land.
Should failures caused by infrastructure be counted the same as test failures?
For an honest reliability picture, track them separately if possible — infrastructure flakiness (agent crashes, network blips) and genuine code/test failures point to very different remediation, even though both count as 'failed builds' in a raw success rate.