01
Long waits for CI
Developers blocked on long sequential test runs before they can merge.
Slow pull request builds, flaky tests and delayed deployments
GitHub Actions CI/CD pipeline speed optimization
Make CI fast enough that nobody waits on it: profile the slow steps, cache what can be cached, split tests across runners and run only what changed.
Symptoms
Signs your platform has this problem
If several of these sound familiar, the plan below is where we would start.
02
Flaky tests
Unreliable end-to-end tests that need manual re-runs and erode trust in CI.
03
High CI minute bills
Compute minutes burned on repeated dependency downloads and uncached builds.
Remediation plan
How we fix it, step by step
Each phase ends with a measurement, so you can see what changed before the next one starts.
01
Step profiling
Timing each job step to find slow installs and test bottlenecks.
02
Parallel test shards
Splitting large test suites across parallel runners with balanced shards.
03
Dependency and layer caching
Caching npm, pnpm and Cargo dependencies and Docker layers with BuildKit.
04
Autoscaling runners
Self-hosted runners that scale on demand and shut down after each job.
Technical checklist
Remediation checklist
What we check before a change goes to production:
- Key actions/cache entries on lockfile hashes for npm and Cargo
- Split long test suites across parallel matrix jobs
- Enable a remote Docker BuildKit cache in GitHub Actions
- Add path filters (for example dorny/paths-filter) to test only changed packages
What we measure
We take a baseline first and report the same measurements after each change, from your own monitoring — evidence, not promised results.
- PR feedback
- Push to all checks green, median and p90
- CI minutes
- Monthly runner minutes and cost
- Flaky rate
- Jobs that pass only on retry, per week
Related service
Cloud & DevOps
Cloud cost optimization, Kubernetes platforms, and CI/CD that make deploys boring — savings and reliability measured in your dashboards, not our deck.
Explore Cloud & DevOpsQuestions
Questions about this remediation
With remote build caches, cached Docker layers, test sharding across parallel runners and, where it pays off, larger self-hosted runners.
OIDC issues short-lived IAM credentials for each workflow run, so there are no long-lived access keys to leak.
Related playbooks
Other engineering problem playbooks
Kubernetes autoscaling and compute cost fix with Karpenter
Fix slow pod scheduling and idle nodes: set accurate resource requests, replace Cluster Autoscaler with Karpenter, and run interruptible workloads on spot.
Near-zero-downtime database migration playbook
Move a production database without a long maintenance window: stream changes with CDC, verify parity with shadow reads, and cut over in a short, rehearsed window with reverse replication ready for rollback.
Startup MVP build and launch
Ship the smallest product that proves your core workflow: scoped with you up front, built on a boring, scalable stack, and handed over with documentation and tests.
SaaS multi-tenant architecture with Row Level Security
Move to a pooled PostgreSQL design where Row Level Security enforces tenant isolation in the database, cutting per-tenant overhead and the risk of a missed WHERE clause.
Want an engineer to look at this with you?
Send us the symptoms and any metrics you have. We'll reply within one business day, set up a call and agree what to measure before anything changes.