Slow CI? How to Reduce CI Pipeline Time

Slow CI is a tax on every pull request. If your CI pipeline is slow, developers context-switch while they wait, batches grow, and bugs reach main because people stop waiting for green. This guide is the hub for reducing CI time: how to measure your CI build time, which fixes pay off first, and where to go for the detail on each one.

Why is my CI pipeline slow?

A CI/CD build time is the sum of four things, and each has a different fix:

1. Queue time: the job waits for a runner. Fix with more capacity, a different runner pool, or fewer concurrent jobs.
2. Setup time: checkout, toolchain install, dependency install, Docker pulls. Fix with caching and smaller images.
3. Work time: compile, lint, test. Fix with parallelism, sharding, incremental builds and test selection.
4. Tail time: artifact upload, report merging, deploy steps, waiting on required checks.

Before you change anything, write down those four numbers for your slowest workflow. In the Actions UI each step shows its duration; the run summary shows the queue wait. Most teams find that one bucket holds more than half the total. If you want to turn that into money, the cost of slow CI calculator multiplies waiting time by team size and hourly cost.

Reduce CI time: the fixes in order of payoff

1. Stop running work you do not need

Path filters, concurrency groups with cancel-in-progress, and skipping docs-only changes cost nothing and often remove 20 to 40 percent of runs. In a monorepo, build only what changed; see the monorepo CI guide.

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true
on:
  pull_request:
    paths-ignore: ["docs/**", "**.md"]

2. Cache dependencies and build output

Restoring a package cache is almost always faster than downloading it. Key on the lockfile hash. The basics are in the caching guide; the limits (10 GB per repository, eviction, pnpm and Docker specifics) are in GitHub Actions cache limits. For container builds, see Docker layer caching.

3. Split the test suite

Sharding runs the suite as several parallel jobs. Wall-clock time falls roughly by the shard count, while billed minutes rise slightly. The test sharding guide covers every major framework and the test sharding planner picks a shard count. Framework-specific advice:

• Playwright tests slow
• Cypress tests slow
• Jest slow
• Vitest slow
• Pytest slow tests

For browser-driven suites in general, read the slow e2e tests pillar.

4. Fix flaky tests, because retries are hidden slowness

A suite with a 5 percent flake rate reruns often. Every rerun is wall-clock time. See how to find and contain flaky tests and, for browser suites, flaky e2e tests.

5. Use the right test mix

A suite that is all end-to-end tests is slow by construction. The unit tests vs e2e tests guide shows a test pyramid that keeps feedback under ten minutes.

6. Use a bigger or faster runner

If the work bucket dominates and the job is CPU-bound, hardware is a legitimate fix. GitHub's standard Linux runner has 2 vCPUs. Options are GitHub larger runners, self-hosted machines and third-party runner providers; the faster GitHub Actions runners guide compares them with dated public prices, and self-hosted vs GitHub-hosted covers the operational trade-offs.

Is it GitHub being slow today?

Sometimes. Queue delays and degraded performance are real and are reported at githubstatus.com. The GitHub Actions slow guide separates platform incidents from problems in your own workflow.

Understand limits and the bill

Slow pipelines and expensive pipelines usually share causes. Know the time limits and delays, the pricing model, and ways to reduce the Actions bill. If you are weighing a platform change, GitHub Actions alternatives explains why most teams keep Actions and change runners, and Blacksmith vs GitHub Actions is a fair look at one provider. Use the CI minutes forecaster to see what faster pipelines do to your usage.

A 30-minute plan

1. Pick the slowest required workflow. Record queue, setup, work and tail times from five recent runs.
2. Add concurrency and path filters.
3. Add or fix the dependency cache; confirm hit rate in the logs.
4. Shard the test job. Start at 4 shards and tune with the planner.
5. Re-measure. Only then try a bigger runner, and measure on your own jobs rather than a vendor benchmark.

Where compiler.dev fits

compiler.dev runs your existing GitHub Actions jobs on faster machines. It was faster than GitHub's 2-core runner on 15 of 19 benchmarked stacks, by 1.1 to 3 times. Linux 8 vCPU is $0.009 per minute and macOS M4 Pro is $0.028 per minute. It falls back automatically to your own runners if needed, and its comparison mode measures your own jobs, so you decide on your numbers rather than ours. Use it after the free fixes above, not instead of them.

FAQ

Why is my CI pipeline so slow?

Usually one of four things: queue time, dependency setup, the test run itself, or retries from flaky tests. Measure each per run before changing anything.

How do I reduce CI time without changing runners?

Cancel superseded runs, skip irrelevant paths, cache dependencies, shard tests, and fix flaky tests. These are free and usually remove a third or more of the time.

What is a good CI build time?

Many teams aim for under ten minutes for the required PR check, because people wait for it. Longer suites should run in parallel, or move slower checks to merge or nightly runs.

Will a faster runner always speed up CI?

No. It helps CPU-bound work such as compiles and test runs. It does little for time spent in queues, network downloads or waiting on external services.