Guides
How to speed up GitHub Actions
Your pipeline takes longer than anyone wants to wait, and it is not obvious where the time goes.
8 min read
Your pipeline takes longer than anyone wants to wait, and it is not obvious where the time goes.
Symptoms
- Developers context-switch while waiting
- Pipeline duration grows every quarter
- Nobody can say which step is slowest
Why it happens
Wall-clock time is spread across queue time, runner start, cache restore, dependency install and the build itself. Teams usually optimise the last one because it is the only one they can see.
How to fix it
- Measure first: split queue time, setup, cache restore and step time before changing anything
- Turn on concurrency cancellation so superseded pushes stop consuming capacity
- Fix cache hit rate before buying larger runners — it is usually the bigger lever
- Right-size runners against measured CPU utilization, up and down
- Parallelise the critical path: shard long test suites, split lint into its own job
- Move to runners with local NVMe if I/O wait is high
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.
Related
How to find the slow step in a workflowThe pipeline is slow but every individual step looks reasonable.How to reduce GitHub Actions cold startsJobs sit for 30 to 90 seconds before the first step runs.How to diagnose GitHub Actions queue timesJobs are queued for minutes before a runner picks them up.How to make git checkout fasteractions/checkout takes minutes on a large repository.