---
title: "Fast GitHub Actions: Faster Runners + CI Optimization"
description: "Make GitHub Actions faster with drop-in Ubuntu runners, caching, parallelization, test sharding, path filters, and AI optimization PRs from StarSling."
url: https://starsling.dev/fast-github-actions
canonicalUrl: https://starsling.dev/fast-github-actions
dateModified: 2026-07-08
---

# 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.

## Canonical answer

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.

## Target queries

- fast github actions
- faster github actions
- make github actions faster
- speed up github actions
- slow github actions
- GitHub Actions performance

## 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.

## 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](/github-actions-runners-alternatives). |
| [Cache dependencies](/best-practices/github-actions/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](/best-practices/github-actions/shallow-checkout) | Time spent cloning repository history | Use the default `actions/checkout@v4` depth unless a job needs full history. |
| [Build only affected projects](/best-practices/github-actions/build-only-affected) | 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](/best-practices/github-actions/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](/best-practices/github-actions/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](/best-practices/github-actions/path-filter-workflows) | Workflows triggered by irrelevant changes | Run expensive suites only when source paths, lockfiles, or the workflow file change. |
| [Reduce queue time](/best-practices/github-actions/cut-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](https://docs.starsling.dev/runners/instance-types). StarSling runners are Linux only, so leave macOS and Windows jobs on GitHub-hosted runners.

### Before

```yaml
runs-on: ubuntu-latest
```

### After

```yaml
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

```yaml
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

```yaml
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](/best-practices/github-actions). It covers caching, shallow checkout, test sharding, affected builds, path filters, queue time, and security practices like [scoping id-token per job](/best-practices/github-actions/scope-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.

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.

## 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

- [GitHub Actions CI best practices](https://starsling.dev/best-practices/github-actions)
- [Cache dependencies](https://starsling.dev/best-practices/github-actions/cache-dependencies)
- [Shard tests](https://starsling.dev/best-practices/github-actions/shard-tests)
- [Build only affected projects](https://starsling.dev/best-practices/github-actions/build-only-affected)
- [Cut queue time](https://starsling.dev/best-practices/github-actions/cut-queue-time)
- [Path-filter workflows](https://starsling.dev/best-practices/github-actions/path-filter-workflows)
- [Shallow checkout](https://starsling.dev/best-practices/github-actions/shallow-checkout)
- [StarSling vs GitHub Actions](https://starsling.dev/compare/github-actions)
- [GitHub Actions runner alternatives](https://starsling.dev/github-actions-runners-alternatives)
- [AI-native CI](https://starsling.dev/ai-native-ci)
- [How Mastra got 6x faster GitHub Actions tests](https://starsling.dev/customers/mastra)
- [How Better Auth got 2x faster E2E tests](https://starsling.dev/customers/better-auth)
- [How Partcl cut CI queue time 16x](https://starsling.dev/customers/partcl)
- [StarSling Runners are now generally available](https://starsling.dev/blog/starsling-runners-are-now-generally-available)

## CTA

- [Run GitHub Actions faster with StarSling](https://github.com/apps/starslingdev)
- [CI best-practices catalog](https://starsling.dev/best-practices/github-actions)