I scanned the GitHub Actions setup of 139 popular JS/TS repos. Only 1 passed 3 basic checks.

robsonheals — Mon, 02 Nov 2026 12:48:22 +0000

I've been building a GitHub Actions linter and didn't want to trust my own heuristics, so I ran it on real projects first: the most-starred JavaScript and TypeScript repos with 1,000–20,000 stars that were active since September 2026. That gave 149 repos, and 139 of them had workflows.

I only checked three things, all boring and all cheap to fix:

Dependency cache: do CI workflows re-download every package on every run?
Concurrency on pull requests: when you push again to a PR, does the outdated run get cancelled?
Job timeouts: does each job have timeout-minutes, or does it fall back to GitHub's default of 6 hours?

The results

Check	Result
Repos with PR workflows that have no concurrency group	97 of 129 (75%)
CI jobs with no `timeout-minutes`	1,329 of 2,181 (61%)
Repos that install deps with no cache in at least one CI workflow	41 of 121 (34%)
Repos that passed all three	1 of 139

These are popular, well-maintained projects run by experienced people. That isn't a criticism of them. It shows how easy these defaults are to miss.

Fix 1: cancel outdated PR runs (3 lines)

Without a concurrency group, every push to a PR starts a full new run while the previous one keeps going. Add this at the top level of the workflow:

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

This only cancels runs on pull requests. Pushes to main, and deploys that run in the same workflow, always finish.

Updated after a great catch in the comments: an earlier version used cancel-in-progress: true, which also cancels runs on main and can interrupt a deploy.

Fix 2: put a timeout on every job (1 line)

A test waiting on a port that never opens, or a --watch flag left on in CI, can hold a runner for 6 hours.

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15   # about 2x the job's normal duration

Fix 3: cache dependencies (1 line)

- uses: actions/setup-node@v7
  with:
    node-version: lts/*
    cache: npm   # or yarn / pnpm

Since setup-node v5, npm projects get this automatically if package.json has a packageManager field set to npm. My scanner accounts for that.

What I deliberately didn't count

I wanted the numbers to be conservative, not scary:

Local composite actions and reusable workflows are skipped for the cache check. I can't see inside them, and many of them do cache.
Release, publish and deploy workflows are skipped. They often avoid caches on purpose, as hardening against cache poisoning.
Explicitly disabled caches (package-manager-cache: false) are treated as a deliberate choice.
I checked 15 flagged repos by hand. After the first round I tightened a rule; in the second round, 6 of 7 were correct. The remaining one tests clean installs on purpose.

The cache number is per repo: a repo counts if at least one CI workflow installs without a cache, even if that particular workflow skips the cache on purpose (a sub-minute lint job, for example).

Bias warning: this is popular open source. Company repos may look better or worse.

Check your own repo

I turned the checks into a free web tool. Paste a public repo and get a 0–100 score with the exact file and line to change. No signup, and nothing is stored:

👉 devrescue.vercel.app

The method and the per-repo raw data are public: devrescue.vercel.app/research

If you think a heuristic is wrong, tell me in the comments. That's the most useful feedback I can get.