How to Measure CI Duration

You cannot optimize what you do not measure. Start by separating queue time from actual run time.

Total "CI took 12 minutes" hides where the time went. Pull per-job timings and split queue from execution to target the real bottleneck.

Queue time vs run time

created_at to started_at is queue/provision time; started_at to completed_at is run time. Slow due to queueing has a different fix (capacity) than slow execution (caching, parallelism).

Pull timings from the API

The jobs API returns per-job timestamps you can aggregate.

shell

gh api repos/OWNER/REPO/actions/runs/RUN_ID/jobs \
  --jq '.jobs[] | {name, started_at, completed_at}'

Track the trend

A single run is noisy. Aggregate p50/p95 duration over weeks to see whether CI is creeping up and which job is responsible.

Key takeaways

Separate queue time from run time first.
Pull per-job timings from the jobs API.
Track p50/p95 over time, not single runs.

Related guides

How to Find the Slowest Job in CIPinpoint the slowest job and step in a GitHub Actions workflow using the jobs API and step timings, so you op… 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 Measure and Cut Your CI BillMeasure your GitHub Actions bill by runner OS and workflow, find where minutes go, and cut spend with caching…