Pipeline Throughput Calculator
Calculate pipeline throughput (completed runs per time period) and identify which stage is the bottleneck limiting it.
Inputs
Number of pipeline runs completed in the measurement period.
Elapsed wall-clock time the completed runs are measured over.
Average time spent in the build stage per run.
Average time spent in the test stage per run.
Average time spent in the deploy stage per run.
Pipeline Throughput
7.50runs/hr
Bottleneck Stage
test
Bottleneck Share of Stage Time
68.6%
Step by step
Throughput = completed runs ÷ time period
180 ÷ 24hr
= 7.50 runs/hr
Bottleneck stage = longest average duration
max(60s, 240s, 50s)
= test (240s)
How it works
Pipeline throughput is simply completed runs divided by the elapsed measurement period, giving a rate that's easy to track over time and compare across teams or pipelines. Because throughput for a single-pipeline lane is ultimately capped by the slowest stage in the sequence (the classic theory-of-constraints bottleneck), comparing average stage durations pinpoints exactly where to focus optimization effort to raise the ceiling on how fast pipelines can complete.
Formula
throughput = completedPipelines / timePeriodHours
- C
- Completed pipeline runs
- T
- Measurement period in hours
- \Theta
- Pipeline throughput in runs per hour
Frequently Asked Questions
Is throughput the same as builds-per-hour capacity?
Not quite — this throughput reflects completed runs actually observed in a period, which is shaped by both pipeline stage durations and available executor capacity, whereas the executor/agent capacity calculators model theoretical maximum capacity independent of observed demand.
Why focus optimization on the bottleneck stage specifically?
In a sequential pipeline, speeding up a non-bottleneck stage doesn't reduce total run time or raise throughput — the bottleneck stage sets the pace, so per theory of constraints, the fastest path to higher throughput is reducing that specific stage's duration or parallelizing it.
How does test parallelism interact with this bottleneck analysis?
If the test stage is the bottleneck (commonly the case), applying the parallel-stage or test-execution-time calculators to split that specific stage across more workers directly attacks the identified bottleneck rather than optimizing stages that aren't limiting throughput.