GitHub Actions Slow? What's Actually Wasting Your Time

#devops #testing #cicd #github

Your GitHub Actions pipeline takes 20 minutes. Your team runs it 50 times a day. That's 16 hours of CI compute daily — and most of it is waste. Developers context-switch while waiting, merge queues back up, and by the end of the week your team has lost an entire engineer's worth of productive time to a slow pipeline.

The fix isn't "buy bigger runners." It's eliminating the waste that's already in your pipeline. Here are the five biggest time wasters and how to fix each one.

The hidden cost of slow CI

Slow CI doesn't just waste compute. It creates a cascade of productivity losses that compound across your team:

Developer wait time: A developer waiting 20 minutes for CI is not coding. They're checking Slack, reading Hacker News, or starting a second task that creates costly context-switching when CI finishes.
Context switching: Studies show it takes 23 minutes to fully refocus after a context switch. A 20-minute CI wait often creates a 43-minute productivity gap.
Merge queue bottlenecks: When CI takes 20 minutes, your merge queue can process 3 PRs per hour at most (serially). With a team of 10 developers, PRs stack up and block each other.
Deployment velocity: Slow CI means fewer deployments per day, which means larger batch sizes, which means more risk per deploy. It's a vicious cycle.

The math is simple: if your CI takes 20 minutes and you have 10 developers, optimizing it to 8 minutes saves 2 hours of developer wait time per day. At $150/hour loaded engineering cost, that's $300/day or $78,000/year.

Time waster #1: Flaky test reruns

This is the single biggest source of CI waste, and it's the one most teams underestimate. When a flaky test fails, developers re-run the entire pipeline. That re-run wastes 100% of the compute — you're running the same tests again just to get a different roll of the dice.

The numbers are staggering. In our analysis of 10,000 GitHub Actions workflow runs, we found that 15-25% of CI compute is wasted on flaky test reruns. That means if you spend $10,000/month on GitHub Actions, $1,500 to $2,500 is literally burned on re-running tests that aren't actually broken.

The fix: Identify and quarantine flaky tests. You can't fix what you can't measure. Start by identifying which tests are flaky, then quarantine them so they don't block CI while you fix the root causes.

Time waster #2: No dependency caching

Every CI run that starts with npm install or pip install -r requirements.txt from scratch is downloading the same packages over and over. For a typical Node.js project, this wastes 1-3 minutes per run. Multiply that by 50 runs/day and you're losing 1-2.5 hours daily.

The fix: Use actions/cache or built-in caching. Pro tip: npm ci is faster than npm install in CI because it skips the lockfile resolution step.

Time waster #3: Running all tests on every PR

If a PR only changes a README file, there's no reason to run your entire test suite. Yet most teams configure their pipeline to run everything on every push. For large monorepos, this wastes enormous amounts of compute.

The fix: Use path filters and affected test detection.

Time waster #4: Sequential jobs that could be parallel

Many teams structure their pipeline as a linear chain: lint → type-check → unit tests → integration tests → e2e tests. Lint and tests don't depend on each other — they can run simultaneously.

The fix: Parallelize independent jobs. With parallel sharding, you can cut total wall time from 19 minutes to ~4 minutes. You pay for more compute-minutes, but your developers get feedback 5x faster.

Time waster #5: Oversized Docker images

If your CI builds Docker images, the image size directly impacts build time, push time, and pull time. A 2GB image takes minutes to push and pull. Most of that size is build dependencies that aren't needed at runtime.

The fix: Multi-stage builds with slim base images.