How to Find the Slowest Job in CI
Wall-clock time is set by the critical path. Find the job and step on it, then optimize that.
Optimizing a fast job does nothing for total time. Identify the job that gates everything, then the slowest step within it.
Rank jobs by duration
Sort the jobs API output to surface the slowest job in a run.
shell
gh api repos/OWNER/REPO/actions/runs/RUN_ID/jobs \
--jq '.jobs | sort_by(.completed_at) | .[] | {name, started_at, completed_at}'Drill into steps
Each job lists step-level timestamps. The slowest step (install, build, a test shard) is where to focus.
Mind the critical path
With needs: dependencies, the longest dependent chain sets total time. Speeding a parallel job that finishes early changes nothing.
Key takeaways
- Total time is set by the critical-path job.
- Rank jobs, then steps, by duration.
- Optimizing off-critical-path jobs does not help wall-clock.
Related guides
How to Measure CI DurationMeasure GitHub Actions duration accurately: queue time vs run time, per-job timing from the API, and trends o…
How to Profile a GitHub Actions WorkflowProfile a GitHub Actions workflow end to end: per-step timing, the critical path of needs dependencies, cache…
How to Debug Why CI Is SlowA systematic checklist to debug slow GitHub Actions: separate queue from run time, find the critical path, ch…
How to Split a Slow Test Suite in CIBreak a long-running test suite into parallel CI shards: choose a split strategy, fan out with a matrix, and…