Speed up GitHub Actions

Make GitHub Actions faster

Making GitHub Actions faster comes down to a few things: the runner has to be powerful enough for the work, jobs have to start without waiting in a queue, and the workflow should not repeat work it could cache, skip, or parallelize. Which one matters most depends on the pipeline. The two levers are faster runner hardware and workflow optimization, and which one you're hitting decides which to reach for.

Prompt for your coding agent View in Markdown

How StarSling works

Topics covered: This guide covers how to tell whether your bottleneck is the runner, the queue, or the workflow, and what to change in each case.

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.
If you are not sure why the run is slow yet, start by diagnosing why GitHub Actions builds are slow, then come back here for the speedup plan.
Prefer the do-it-for-me path? run the free /ci-speedup skill to find your blocking check, then use the sections below to review its diagnosis and fix.

Start here: hand this to your agent

You do not have to do any of this by hand. Paste this prompt into a coding agent pointed at your repository. It profiles a slow run, then opens a small PR with the fixes that matter for your bottleneck, and explains its reasoning. The rest of this guide is what it will be doing, and how to check its work.

Prompt for your coding agent

Inspect .github/workflows/*.yml and .github/workflows/*.yaml. First, report where the wall-clock time goes on a recent slow run: queue wait, checkout, dependency install, build, or tests. Then find changes that would make GitHub Actions faster without changing product behavior, ordered by how much time each one saves. Prioritize caching, shallow checkout, affected builds, test sharding, path filters, concurrency, queue-time reduction, and removing dead steps. Skip anything that only helps a stage that is not the bottleneck, and say so. Do not weaken permissions or change deployment behavior without explanation. Open a small PR with before/after reasoning.

GitHub Actions performance: where the time goes

The fix depends on which of these dominates, so profile a 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 - see Docker CI on GitHub Actions for the workflow that fixes it.
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.

Sources: GitHub's own limits

The cache ceiling, the billing rounding, and the job-execution limit on this page are GitHub's numbers, not ours. GitHub publishes each of them:

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.
Configure the GitHub Actions cache	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 so a new push supersedes the old run. Scope the cancel to pull requests (`cancel-in-progress: ${{ github.event_name == 'pull_request' }}`) rather than setting a bare `true`, which would also kill in-flight runs on `main` and on release tags.
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.

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
    with:
      version: 10   # required unless package.json sets "packageManager"
  - 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.

Treat a speedup GitHub Actions ticket as a measurement task first. A random list of YAML tricks is less useful than proving whether the runner, the queue, or the workflow is the bottleneck.

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.

Fast GitHub Actions runners compared

Several vendors sell drop-in runners faster than GitHub's. They all run jobs faster. Only StarSling also opens AI optimization PRs that improve the pipeline over time. Each vendor claim is carried from the runner comparison table, which cites its source and dates it.

StarSling is self-driving CI: fast runners plus agents that open optimization PRs to enforce best practices. Its runner families are Linux only: Ubuntu 24.04, so macOS and Windows jobs stay on GitHub-hosted runners.

StarSling vs Depot for GitHub Actions - Container builds, Depot Cache (depot.dev/docs/cache/overview), GitHub Actions runners, and Depot CI (products (depot.dev/)). Runner families: Linux, macOS, and Windows (runner types (depot.dev/docs/github-actions/runner-types)).
StarSling vs Blacksmith runners for GitHub Actions - Fast drop-in runners plus caching and build infrastructure; its docs list no agent that opens optimization PRs. Runner families: Linux x64 and ARM and macOS, with Windows Server 2025 in public beta (instance types (docs.blacksmith.sh/blacksmith-runners/overview)).
StarSling vs WarpBuild - Fast drop-in runners plus a container-build service; its docs list no agent that opens optimization PRs. Runner families: Linux x64 and ARM64, macOS, and Windows (cloud runners (www.warpbuild.com/docs/ci/cloud-runners)).

Choose by bottleneck rather than by brand. If docker build dominates the run, a remote builder moves that build off the machine running the job. If install, test, and package steps dominate, they all run on the runner, which is the case a one-line runs-on swap actually changes. If the pipeline itself repeats work, no runner fixes that: caching, sharding, and path filters do. The baseline all of these are measured against is GitHub's own hosted runners.

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.

When StarSling helps most

StarSling tends to help most when:

Your workflows already run on ubuntu-latest or ubuntu-24.04.
Build and test jobs are CPU-bound, queue-bound, or slowed down by repeated setup work.
Your CI spends significant time on dependency installs, test bottlenecks, cache misses, or serial jobs.
You want faster runners plus reviewable optimization PRs, instead of maintaining every CI speedup by hand.
You want to keep GitHub Actions syntax, PR checks, and branch protections.

None of this guarantees a speedup for every workflow. A pipeline dominated by network waits, deploy approvals, fixed sleeps, or macOS and Windows jobs will not move much on faster Linux runners. StarSling is not a replacement for GitHub Actions syntax; it runs your existing GitHub Actions workflows on StarSling runners. Moving the repository host too? See StarSling CI for Cursor Origin for GitHub Actions-style workflows without a GitHub dependency.

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.

Which parts of a GitHub Actions run can I make faster?

The ones that usually dominate the run: runner CPU, queue time, dependency installs without a warm cache, Docker build time, jobs running serially, oversized test suites, cache misses, required checks on the critical path, and workflows that run on irrelevant file changes. Profile a run first, then start with whichever one owns the most wall-clock time.

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.

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 August 20, 2026