Speed up GitHub Actions

Fast GitHub Actions

Slow GitHub Actions usually comes down to a few things: the runner isn't powerful enough for the work, jobs wait in a queue before they start, or the workflow repeats work it could cache, skip, or parallelize. Which one dominates depends on the pipeline. This guide covers both levers (faster runner hardware and workflow optimization) and how to tell which one you're hitting.

View in Markdown

fast github actionsfaster github actionsmake github actions fasterspeed up github actions

To make GitHub Actions faster, combine faster Ubuntu runners with workflow optimization: cache dependencies, use shallow checkout, split independent jobs, shard long tests, scope work to affected projects, add safe path filters, reduce queue time, and remove dead steps. Measure where the time goes first, then fix the stage that dominates.

Real results

16×

shorter CI queue time at Partcl

6×

faster test suites at Mastra

2×

faster E2E tests at Better Auth

TL;DR

Measure first: profile where the wall-clock time goes (queue, checkout, install, build, or tests) before changing anything.
The two levers are faster runner hardware and a leaner workflow (caching, parallel jobs, test sharding, path filters, queue-time reduction). Most slow pipelines need both.
Faster runners cut execution time; workflow changes cut the work itself. Neither fixes network- or approval-gated waits; those need workflow changes, not hardware.

Why GitHub Actions feels slow

Here is where the time usually goes. The fix depends on which of these dominates, so profile a slow run before changing anything.

Runner CPU performance: slow jobs spend real time on CPU-bound builds, test transforms, compression, and language toolchains.
Cold starts and queue time: a job that waits for capacity feels slow before a single step runs.
Dependency install time: missing or broken caches make every run download and rebuild the same packages.
Docker build time: image builds can redo layers when cache scopes or contexts are wrong.
Serial workflows: independent jobs or steps may wait behind each other even when they could run in parallel.
Oversized test suites: one large test job becomes the long pole for the whole PR.
Required checks that block merges: a slow required check defines the developer wait, even if other checks finish quickly.
Cache misses: bad cache keys, missing lockfiles, or wrong cache paths erase expected speedups. The Actions cache also defaults to 10 GB per repository (admins can raise it, with usage beyond that billed) and evicts least-recently-used entries, so large or contended caches quietly start missing.
Jobs running on irrelevant file changes: docs-only or unrelated changes can trigger expensive suites.
Per-minute billing rounding: GitHub rounds each job up to the next full minute, so many short jobs, re-runs, and matrix legs cost more than the raw compute suggests.

Fastest ways to speed up GitHub Actions

Use the table as a practical order of operations. Measure where the time goes first, then apply the fixes that match your bottleneck.

Fix	What it improves	Example
Use faster runners	CPU-bound build and test time, and available runner capacity	Swap `runs-on: ubuntu-latest` for a faster Ubuntu runner; see runner alternatives.
Cache dependencies	Repeated package downloads and rebuilds	Use `cache: pnpm` on `actions/setup-node` and key the cache on `pnpm-lock.yaml`.
Use shallow checkout	Time spent cloning repository history	Use the default `actions/checkout@v4` depth unless a job needs full history.
Build only affected projects	Redundant build and test work in monorepos	Run Nx, Turborepo, Bazel, or changed-test modes against the merge base with a full-run fallback.
Shard tests	A single long test job on the PR critical path	Use a matrix and framework sharding such as Playwright `--shard`.
Cancel superseded runs	Wasted runs on commits you've already pushed past	Add a `concurrency` group keyed on the ref with `cancel-in-progress: true` so a new push cancels the old run.
Use path filters carefully	Workflows triggered by irrelevant changes	Run expensive suites only when source paths, lockfiles, or the workflow file change.
Reduce queue time	Waiting before jobs start	Scope concurrency per ref and use runner capacity that can absorb PR bursts.
Cap runaway jobs	Billable minutes and PRs stuck behind a hung step	Set `timeout-minutes` on jobs and long steps; GitHub otherwise lets a hung job run up to 6 hours.
Remove dead steps	Steps that no longer affect build, test, or deploy results	Delete obsolete setup, duplicate installs, old upload steps, and unused service startup.
Split or merge jobs intelligently	Critical path shape and repeated setup overhead	Split independent slow jobs, but merge tiny jobs when checkout and install dominate.
Right-size runners	Jobs bottlenecked by CPU, memory, or parallelism	Use larger Linux runners for CPU-heavy jobs and smaller runners for short checks.
Avoid fixed sleeps	Idle time hidden inside tests or service setup	Replace `sleep 30` with service health checks, retries, or readiness probes.
Use Docker layer caching where appropriate	Repeated image build layers	Cache BuildKit layers for Docker-heavy pipelines when the cache can be reused safely. Note that emulated multi-arch builds (QEMU) are far slower than native hardware.

Use faster runners
What it improves
CPU-bound build and test time, and available runner capacity
Example
Swap runs-on: ubuntu-latest for a faster Ubuntu runner; see runner alternatives.
Cache dependencies
What it improves
Repeated package downloads and rebuilds
Example
Use cache: pnpm on actions/setup-node and key the cache on pnpm-lock.yaml.
Use shallow checkout
What it improves
Time spent cloning repository history
Example
Use the default actions/checkout@v4 depth unless a job needs full history.
Build only affected projects
What it improves
Redundant build and test work in monorepos
Example
Run Nx, Turborepo, Bazel, or changed-test modes against the merge base with a full-run fallback.
Shard tests
What it improves
A single long test job on the PR critical path
Example
Use a matrix and framework sharding such as Playwright --shard.
Cancel superseded runs
What it improves
Wasted runs on commits you've already pushed past
Example
Add a concurrency group keyed on the ref with cancel-in-progress: true so a new push cancels the old run.
Use path filters carefully
What it improves
Workflows triggered by irrelevant changes
Example
Run expensive suites only when source paths, lockfiles, or the workflow file change.
Reduce queue time
What it improves
Waiting before jobs start
Example
Scope concurrency per ref and use runner capacity that can absorb PR bursts.
Cap runaway jobs
What it improves
Billable minutes and PRs stuck behind a hung step
Example
Set timeout-minutes on jobs and long steps; GitHub otherwise lets a hung job run up to 6 hours.
Remove dead steps
What it improves
Steps that no longer affect build, test, or deploy results
Example
Delete obsolete setup, duplicate installs, old upload steps, and unused service startup.
Split or merge jobs intelligently
What it improves
Critical path shape and repeated setup overhead
Example
Split independent slow jobs, but merge tiny jobs when checkout and install dominate.
Right-size runners
What it improves
Jobs bottlenecked by CPU, memory, or parallelism
Example
Use larger Linux runners for CPU-heavy jobs and smaller runners for short checks.
Avoid fixed sleeps
What it improves
Idle time hidden inside tests or service setup
Example
Replace sleep 30 with service health checks, retries, or readiness probes.
Use Docker layer caching where appropriate
What it improves
Repeated image build layers
Example
Cache BuildKit layers for Docker-heavy pipelines when the cache can be reused safely. Note that emulated multi-arch builds (QEMU) are far slower than native hardware.

Drop-in runner migration example

A runner migration is intentionally small. Keep GitHub Actions syntax, keep existing actions, and change the runner label on your Ubuntu/Linux jobs to a supported StarSling instance type. StarSling runners are Linux only, so leave macOS and Windows jobs on GitHub-hosted runners.

Before

runs-on: ubuntu-latest

After

runs-on: starsling-ubuntu-24.04

Keep GitHub Actions syntax.
Keep existing actions.
Change runner labels on Ubuntu/Linux jobs.
StarSling runners are Linux only, so leave macOS and Windows jobs unchanged.

Workflow optimization example

Faster hardware helps immediately, but missing caches still waste time. Cache keys should include lockfiles so the cache changes when dependencies change and hits when they do not.

Before: dependency cache missing

steps:
  - uses: actions/checkout@v4
  - uses: pnpm/action-setup@v4
  - uses: actions/setup-node@v4
    with:
      node-version: 22
  - run: pnpm install --frozen-lockfile
  - run: pnpm test

After: pnpm cache keyed on the lockfile

steps:
  - uses: actions/checkout@v4
  - uses: pnpm/action-setup@v4
  - uses: actions/setup-node@v4
    with:
      node-version: 22
      cache: pnpm
      cache-dependency-path: pnpm-lock.yaml
  - run: pnpm install --frozen-lockfile
  - run: pnpm test

Use the lockfile in the cache key or setup action cache dependency path.
A warm cache helps most on repeated PR runs and unchanged dependency graphs.
Measure install time before and after so the PR proves its impact.

Fast runners vs optimized workflows

Fast runners reduce execution time. If a build is CPU-bound, a stronger Ubuntu runner can make the same workflow finish sooner without changing the YAML beyond runs-on. They won't help work that isn't CPU-bound: a step waiting on a third-party API, a deploy approval, or a fixed sleep takes just as long on faster hardware.

Optimized workflows reduce unnecessary work. Caching, sharding, affected builds, path filters, and removing dead steps make the pipeline do less work or do it in parallel, and they fix the waits faster hardware can't.

Most slow pipelines need both. A faster runner is a one-line runs-on change; the workflow changes take more effort but compound. StarSling combines the two (drop-in Ubuntu runners plus agents that open the workflow changes as reviewable PRs), but every optimization here can be applied by hand; see the best-practices catalog below.

See the GitHub Actions CI best-practices catalog

For detailed YAML, guardrails, and per-practice prompts, read the GitHub Actions CI best-practices catalog. It covers caching, shallow checkout, test sharding, affected builds, path filters, queue time, and security practices like scoping id-token per job.

Agent prompt

Paste this into a coding agent when you want a small PR that speeds up GitHub Actions without changing product behavior.

Prompt for your coding agent

Inspect .github/workflows/*.yml and .github/workflows/*.yaml. Find changes that would make GitHub Actions faster without changing product behavior. Prioritize caching, shallow checkout, affected builds, test sharding, path filters, concurrency, queue-time reduction, and removing dead steps. Do not weaken permissions or change deployment behavior without explanation. Open a small PR with before/after reasoning.

Key caveats

StarSling is not a new CI syntax and does not replace GitHub Actions workflows.
StarSling runners are Ubuntu/Linux only; macOS and Windows jobs stay on GitHub-hosted runners.
For new accounts, AI-powered optimization PRs are only available to customers on paid plans and are not enabled by default.

FAQ

What is the fastest way to make GitHub Actions faster?

Start with the bottleneck. For CPU-bound jobs, use faster Ubuntu runners. For repeated setup, add dependency caching. For one long test job, shard tests. For irrelevant changes, add safe path filters. Most teams get the best result by combining faster runners with workflow optimization.

How do I get fast GitHub Actions without self-hosting runners?

Use a hosted runner provider that supports GitHub Actions runner labels. StarSling is one option for Ubuntu/Linux jobs: install the GitHub App and change the runner label to starsling-ubuntu-24.04.

Why are my GitHub Actions slow?

Common causes are slow runner CPU, queue time, missing dependency caches, Docker build time, serial jobs, oversized test suites, cache misses, required checks on the critical path, and workflows that run on irrelevant file changes.

Are faster GitHub Actions runners enough?

Sometimes, but not always. Faster runners reduce execution time for the work you already run. Workflow optimization reduces unnecessary work. A slow CI pipeline often needs both.

How do I speed up GitHub Actions tests?

Cache dependencies first so each test shard does not repeat setup work, then split long suites with a matrix and the test framework's native sharding support. Keep a full test path for main or merge queues when correctness requires it.

How do I reduce GitHub Actions queue time?

Measure wait-to-start, scope concurrency groups per ref, cancel superseded PR runs, and use runner capacity that can start bursts of jobs promptly. Queue time is different from slow execution time.

Can I make GitHub Actions faster without rewriting my workflows?

Yes. You can change runner labels, add caches, split jobs, shard tests, and tune triggers while keeping GitHub Actions syntax and existing actions. StarSling keeps your workflows and runs supported Ubuntu jobs on StarSling runners.

Is StarSling a replacement for GitHub Actions?

No. StarSling is not a replacement for GitHub Actions syntax or workflows. It is a drop-in runner replacement for supported Ubuntu/Linux GitHub Actions jobs, plus agents that open reviewable optimization PRs.

Related resources

Get started

Run GitHub Actions faster with StarSling

Keep GitHub Actions workflows. Move supported Ubuntu jobs to faster runners, then let optimization PRs improve the workflow over time.

Run Actions faster CI best-practices catalog

Last reviewed July 8, 2026