Your CI/CD Pipeline
is Too Slow

"Our deploys take 45 minutes." "We can only ship twice a week." "Engineers batch changes because the pipeline is too slow."

I hear these complaints constantly. And the first instinct is always to blame the CI/CD tool — let's switch from Jenkins to GitHub Actions! Or from CircleCI to GitLab CI! That'll fix it.

It almost never does. Because the tool is rarely the bottleneck. The pipeline is slow because of what's in it, not what runs it.

The Diagnosis

When I'm called in to fix a slow pipeline, the first thing I do is profile it. I break down the total time into categories:

• Dependency installation — npm install, pip install, bundle install, docker pull. Often 30–50% of total pipeline time.
• Testing — Unit tests, integration tests, E2E tests. Usually the second biggest chunk.
• Building — Compilation, bundling, image building. Varies by language.
• Deployment — The actual shipping step. Often fast, but can be slow with manual gates.
• Wait time — Queue time, resource contention, manual approvals.

The Quick Wins

These almost always make an immediate difference:

• Cache your dependencies — This is table stakes. If your CI downloads the same 500 npm packages on every run, you're burning time and money.
• Run tests in parallel — Most modern CI tools support parallelism. Use it.
• Only run what changed — If you changed the frontend, don't run backend tests. Path-based filtering can cut pipeline time dramatically.
• Kill the flaky tests — Flaky tests that require retries are silent time killers. Fix them or quarantine them.
• Right-size your runners — Underpowered CI runners are a false economy. The time cost exceeds the compute savings.

The Deeper Fixes

Once the quick wins are done, look at the structural issues:

• Test strategy — Are you running too many E2E tests that should be integration tests? Too many integration tests that should be unit tests? The testing pyramid exists for a reason.
• Monorepo tooling — If you have a monorepo, you need build graph tools (Nx, Turborepo, Bazel) to avoid rebuilding everything on every change.
• Docker image optimization — Multi-stage builds, smaller base images, layer caching. A 2GB image that could be 200MB is costing you on every build.
• Manual approvals — Every manual gate in your pipeline is a potential 4–24 hour delay. Are they all necessary?

The fastest pipeline I ever built took 90 seconds from commit to production. It wasn't magic — it was ruthless elimination of waste. Your pipeline should be a highway, not a traffic jam.