What Is the Critical Path of a Pipeline? The Longest Chain
The critical path of a pipeline is the longest chain of dependent jobs; it sets the floor on how fast the whole pipeline can finish.
No matter how many machines you throw at a pipeline, it cannot finish faster than its longest dependency chain. That chain is the critical path. Every job on it must wait for the one before it, so their durations add up. Find the critical path and you have found the one thing limiting your pipeline's speed.
Why the longest chain rules
Jobs off the critical path run in parallel and finish early; they do not extend total time. Jobs on the critical path run in sequence, so their durations sum. The pipeline finishes only when the last job on this chain completes.
Finding the critical path
Trace the dependency graph from start to finish and find the path whose total job duration is largest. That path, not any single slow job in isolation, determines the minimum run time.
A quick example
If build (5m) -> test (10m) -> deploy (3m) is the longest chain, the pipeline takes at least 18 minutes even if ten other jobs run in parallel alongside. Speeding up a parallel job changes nothing; speeding up test changes everything.
Shortening the critical path
- Split a slow critical job into parallel shards (fan-out).
- Cache work so a critical step skips when unchanged.
- Remove unnecessary dependencies that force serialization.
- Move non-essential work off the critical path.
The critical path and runners
Queue time on a critical job extends the whole critical path, so a job waiting for a runner is as costly as a slow job. Managed runners (Latchkey) reduce queue time on critical jobs by keeping warm capacity ready, so the critical path is run time, not waiting.
Key takeaways
- The critical path is the longest chain of dependent jobs in a pipeline.
- It sets the minimum run time; off-path jobs do not extend it.
- Speed up, shard, or cache the critical path to make the pipeline faster.