Your GitHub Actions matrix has grown to 60 jobs per pull request. How do you decide what to keep?

## Frame it as value per leg, not job count Sixty jobs is not automatically wrong; sixty jobs where fifty-five have never independently caught a defect is. The question a lead has to answer is what marginal risk each dimension removes and what it costs in feedback latency, runner spend, and queue contention with every other repository sharing the capacity. ## Step 1: measure what the matrix actually catches Use the run history — the Actions API exposes runs, jobs, and conclusions — to build a simple table over a meaningful window: for each matrix leg, how often it failed, and how often it failed **when no other leg failed**. That second number is the leg's unique yield, and it is usually brutally revealing. Legs with high unique yield are earning their place. Legs that only ever fail alongside the Linux job are duplicates of it. Legs that fail intermittently and pass on re-run are flaky and are costing trust as well as minutes. Also measure the human cost: the median wall-clock time from push to a complete verdict, and the re-run rate. If the matrix takes 40 minutes and a third of runs are re-run, the real cost is engineers context-switching, which dwarfs the compute bill. ## Step 2: tier the coverage Most matrices collapse cleanly into three tiers: - **Pull request** — the smallest set that catches the defects a merge would ship: usually the primary platform, the oldest and newest supported toolchain, and anything with a genuine history of unique failures. - **Merge or pre-release** — broader coverage, run once per merge to the default branch, where a slower result is acceptable because nobody is waiting on it to press a button. - **Scheduled** — the exhaustive sweep, run nightly or weekly, catching environment drift and long-tail combinations. Failures here need an owner and a triage path, or the schedule becomes noise. The tiering conversation is easier than the deletion conversation: nobody is losing coverage, it is moving to where it costs less. ## Step 3: reduce the cost of what remains - **Change detection.** A dynamic matrix generated from changed paths turns a monorepo's fixed 30 legs into the two that the pull request touched. This is often the single largest win. - **Caching that actually hits.** A key fingerprinted on the lockfile with a stable restore-key prefix, and per-leg keys that include the OS and toolchain so legs do not collide. Verify the hit rate rather than assuming it. - **Split slow legs from fast ones.** Put quick checks in one job that fails early, and keep the expensive matrix behind it, so an obvious mistake does not spend the whole product. - **Right-size the runner.** A larger hosted runner or a self-hosted machine can be cheaper in wall-clock terms than parallelising further, especially where the workload is single-process. ## Step 4: set the policy explicitly Write down the rules so the matrix does not regrow: - A stated feedback-latency target for pull-request CI; anything that breaks it must justify itself. - `fail-fast: false` on the small compatibility matrix — with few legs, complete information is worth more than the saved minutes — and the default on large shard matrices. - `max-parallel` only where a shared resource or a shared runner fleet genuinely requires it, not as a general throttle. - A rule for adding a dimension: it comes with the failure it is expected to catch, and it is reviewed after a quarter against its unique yield. - Flaky legs get fixed or removed on a deadline; "re-run it" is not a policy. ## Step 5: mind the check surface Matrix legs surface as individually named checks, and repository policy may require specific check names. Renaming or removing legs can therefore silently leave a required check that never reports — blocking every merge — or quietly drop one that was protecting the branch. Coordinate matrix changes with whoever owns the branch policy, and prefer a single aggregating job that the policy requires, with the matrix behind it, so the check surface stays stable while the matrix evolves. ## What a strong answer sounds like Evidence first (unique yield per leg, latency, re-run rate), then tiering rather than deletion, then cost reduction through change detection and caching, then a written policy with a latency budget — and an explicit note about the required-check surface, which is the part that turns a tidy matrix cleanup into a merge outage.