When would you split a GitHub Actions pipeline into more parallel jobs rather than more steps?

## The two things a job boundary actually is A job boundary in GitHub Actions is simultaneously a **parallelism boundary** and an **isolation boundary**. Every design argument comes from one of those two, and every cost comes from the fact that isolation is literal: separate runner, separate filesystem, separate process space, separate token scope. ## What splitting buys **Wall-clock time.** Jobs without a `needs:` edge between them run at the same time. If lint takes 3 minutes and the test suite takes 12, running them as one job costs 15 and as two costs 12. This is the only lever that shortens a pipeline without making any individual piece faster. **Isolation of privilege.** `permissions` is declared per job, as is `environment`. A build job that needs nothing but read access and a deploy job holding an OIDC `id-token` claim and sitting behind an environment's reviewers cannot be the same job — the split is the mechanism that keeps the powerful credential out of the job that compiles untrusted contributor code. **Re-run granularity and legibility.** A failed job can be re-run on its own, and a job is the unit that shows up by name in the run's status list. When a stage is named `integration-tests` rather than being step 7 of `build`, both a human and any policy that references check names can talk about it directly. **Different execution environments.** A job that must run on a different `runs-on` target, or in a container, cannot share a job with one that does not. ## What splitting costs **Fixed setup, paid again.** The new runner starts empty. Checkout, language toolchain, dependency cache restore, container image pulls — all repeated. For a job whose real work is 40 seconds, that overhead can exceed the work, and you have made the pipeline slower and more expensive at the same time. **Data transfer instead of a filesystem.** Steps in one job share `github.workspace`; jobs share nothing. Moving a build output means `actions/upload-artifact` in the producer and `actions/download-artifact` in the consumer, which costs upload and download time proportional to size, plus storage. Small strings can ride the `outputs:`/`needs.<job_id>.outputs` channel instead, but that carries no files. With `actions/upload-artifact@v4` artifacts are immutable and each name must be unique within a run, so a fan-out that uploads must name per-variant artifacts and a fan-in job merges them. **Total minutes rise.** Hosted runner usage is billed per job, and each job's time is rounded up, so many short jobs waste more than a few long ones. Parallelism trades money for latency; that is often the right trade, but say so deliberately. **Concurrency ceilings.** Every account has a limit on how many jobs run at once, and a self-hosted pool has however many runners you bought. Past that point, additional jobs queue rather than parallelise, and a wide fan-out can starve *other* pipelines sharing the pool. The eighteenth parallel job may add zero wall-clock benefit while delaying a colleague's build. ## The decision, made concrete Split when **all** of these hold: the pieces are genuinely independent (no `needs:` edge would be needed anyway); each piece is meaningfully longer than the setup it will now repeat; and the data crossing the boundary is small, or the consumer would have rebuilt it anyway. Split **regardless of duration** when the boundary is about privilege, environment protection, or a different runner target — there the isolation, not the speed, is the point. Keep it as steps when the pieces share a large working set (a compiled tree, a node_modules directory, a container just brought up), when one piece is trivially short, or when the split would only serve to make the YAML look tidier. ## Shaping the graph Once split, optimise the **critical path**: the longest chain of `needs:` edges weighted by each job's duration. Two habits pay off repeatedly. First, delete edges that exist only for narrative order — a `notify` job that needs everything is fine, but a lint job that needs checkout-as-a-job is pure serialisation. Second, push the expensive fan-out as early as possible and let the fan-in job be cheap, so that failures surface in parallel rather than one stage at a time. A related refinement is *conditional* work: a job whose `if:` excludes it on most runs costs nothing when skipped, so splitting rarely-needed heavy work (a full end-to-end suite, a security scan) into its own gated job is usually right even when the raw duration argument is marginal. ## The signal to watch The number worth tracking is not job count but pipeline p95 wall-clock plus runner minutes per run. A refactor that halves wall-clock while doubling minutes is a deliberate purchase; one that raises both is a mistake, and it usually turns out to be a fan-out of jobs too small to repay their own checkout.