DEV Community: depmedicdev-byte

I scanned 5 popular OSS repos in 5 minutes. Here's what I found.

depmedicdev-byte — Tue, 28 Apr 2026 03:06:33 +0000

Earlier today I shipped scan.html: a one-page in-browser tool that takes any public GitHub repo URL, fetches its .github/workflows/*.yml, and returns a per-workflow report using ci-doctor (14 rules) and gha-budget (per-job pricing). Runs entirely client-side via the GitHub public API. No signup, nothing uploaded.

To make sure it actually works on real-world repos and not just on the canned examples I built it against, I picked 5 well-known npm-ecosystem repos that I had not specifically optimized for, and ran them through. All 5 are maintained by experienced engineers. None of these are random small repos; they all matter.

The 5 repos

Repo	Workflows	Per-run $	Modeled $/mo*	Findings (err / warn / info)
axios/axios	8	$2.62	$2,362	40 (12 / 27 / 1)
eslint/eslint	8	$1.54	$1,382	46 (0 / 40 / 6)
vitejs/vite	12	$1.09	$979	26 (0 / 25 / 1)
prettier/prettier	17	$1.02	$922	32 (6 / 23 / 3)
sveltejs/svelte	5	$0.70	$634	14 (0 / 10 / 4)
Total	50	$6.97	$6,279	158 (18 / 125 / 15)

*Modeled at 30 runs/day, 8 min/job, on standard ubuntu-latest GitHub-hosted runner pricing. Real spend depends on actual run frequency, runner choice, and OSS rate-limit credits. The point of the column is comparison, not accusation.

The same 3 rules show up in all 5 repos

This is the part I find genuinely interesting. These repos have nothing in common architecturally - vite is a bundler, axios is an HTTP client, eslint is a static analyzer, etc. - but the top-3 ci-doctor findings are nearly identical across all of them:

missing-timeout (76 hits across 5 repos). No timeout-minutes: on jobs, so a hung step bills until GitHub's 6-hour default cap. Every repo has this.
missing-concurrency (20 hits). Push 3 commits to a PR in 30 seconds, you get 3 stacked CI runs and GitHub bills all 3. concurrency: with cancel-in-progress: true kills the first 2 in milliseconds. Free 30-50% CI savings on PR-heavy repos.
missing-cache (16 hits, mostly in eslint). actions/setup-node without cache: 'npm' / 'pnpm' / 'yarn' means every job re-downloads node_modules. Slow and expensive.

The interesting outlier is axios/axios with 12 error-severity findings. All 12 are deprecated-action: workflows still pinned to actions/checkout@v3, actions/setup-node@v3, and actions/upload-artifact@v3. v3 of upload-artifact was deprecated in late 2024 and the v3 endpoint is being shut off. These are not "save 3% of your CI bill" findings; these are "your CI will silently start failing" findings.

Why these specific 3 are everywhere

My theory: GitHub Actions doesn't push you to add any of them. The workflow files YAML-validates fine without a timeout, without concurrency, without a cache. The CI passes. The PR ships. There is no linter built in to nudge anyone toward better defaults. So the same 3 smells survive in every repo I scan, including in mine before I built ci-doctor.

This is a tooling problem, not a competence problem. The maintainers of all 5 of these repos are excellent engineers. The smells are just invisible until something points at them.

What to do about it (5-minute fixes)

For each of the top 3 rules, here's the smallest possible change:

1. Add a job-level timeout

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15   # <-- add this
    steps: ...

2. Add concurrency at workflow scope

# top of every workflow that runs on PRs
concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.ref }}
  cancel-in-progress: true

3. Tell setup-node what package manager you use

- uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'npm'      # or 'pnpm' or 'yarn'

Or just run npx ci-doctor --fix and let it patch missing-concurrency, missing-timeout, wide-trigger, and artifact-no-retention in place. The other 10 rules need a human to look at them, but those 4 are mechanical.

Run this scan on your own repo

Free, browser-only, no signup: https://depmedicdev-byte.github.io/scan.html

Paste any public GitHub repo URL. Get the same per-workflow report above for your own code in about 10 seconds. Shareable result URL. Nothing uploaded.

Methodology

All 5 repos were pulled via the GitHub public API, no auth.
Each .github/workflows/*.yml was passed through ci-doctor 0.4.1 (14 rules) and gha-budget for per-job pricing.
Cost = sum of all jobs at GitHub-hosted standard ubuntu-latest rates, assuming 8 min/job.
Monthly = per-run * 30 runs/day * 30 days. Self-hosted and large-runner jobs are unpriced.
This is the same engine that runs in the browser at /scan.html. The 20-repo version of this analysis lives at /benchmarks.html with per-repo deep dives.

What this is NOT

This isn't an attack on any of these projects. They all ship excellent software, and "modeled $/mo" is not the same as "actual $/mo" - large OSS projects get free GitHub Actions credits, run things conditionally, and use self-hosted runners for the heavy lifting. The point is that the same three workflow-YAML patterns show up in every repo I scan, including mine before I started building ci-doctor.

Free CLIs: ci-doctor, gha-budget, pin-actions. All MIT.

If the in-browser report flags 5 things in your workflow and you'd rather just copy a known-good template than fix one rule at a time, the Cut Your CI Bill cookbook ships 30 production patterns: monorepo dispatch, OIDC publish, security gates, matrix trims, the works. $19 one-time, MIT-licensed templates. https://depmedicdev-byte.github.io

GitHub Actions linters compared - actionlint, ci-doctor, sherif, octoscan

depmedicdev-byte — Mon, 27 Apr 2026 23:41:03 +0000

Disclosure: I maintain ci-doctor. The comparison below describes each tool by what it documents and ships, not by my opinion of its authors. Run all four on the same workflow to see for yourself.

GitHub Actions YAML is small enough that one tool could in theory validate everything: syntax, secret hygiene, runner cost, supply-chain pinning, deprecated actions, untrusted inputs. In practice, the open-source landscape splits this work across four projects. They overlap in some areas and miss each other in others.

The short version

Concern	actionlint	ci-doctor	sherif	octoscan
YAML / shell syntax	yes	no	no	no
Untrusted input injection	partial	no	no	yes
Action ref pinned to SHA	no	yes	no	yes
Top-level `permissions`	no	yes	no	yes
Concurrency / cancel-in-progress	no	yes	no	no
Job `timeout-minutes`	no	yes	no	no
Cache hint on setup-* actions	no	yes	no	no
Artifact retention-days	no	yes	no	no
Matrix combinatorial explosion	no	yes	no	no
Cost projection in dollars	no	via `gha-budget`	no	no
Auto-fix in place	no	yes	no	no
Auto-pin actions to SHA	no	via `pin-actions`	no	no
SARIF output for Code Scanning	via wrappers	yes	no	yes
Monorepo / multi-repo focus	no	no	yes	no

actionlint

The reference syntax checker. Written in Go, fast, no dependencies. Catches expression syntax errors, unknown event names, unknown contexts, malformed shell scripts in run: blocks (it invokes shellcheck), and a small number of security patterns like ${{ github.event.pull_request.title }} in a shell context.

What it doesn't do: enforce policy. actionlint tells you whether your YAML parses and runs; it does not tell you whether your workflow is cheap, secure-by-default, or maintainable.

Use it for: pre-merge syntax validation. Catching shell quoting bugs.

ci-doctor

Policy and cost focus. Eleven rules grouped into cost, security, and maintenance. Includes --fix mode that auto-applies safe fixes (permissions, concurrency, timeouts, artifact retention) and --sarif for GitHub Code Scanning. Pairs with pin-actions for SHA pinning and gha-budget for dollar cost projection.

What it doesn't do: validate YAML or shell syntax (use actionlint), detect injection vulnerabilities at the expression level (use octoscan), or compare workflows across repos (use sherif).

Use it for: cost discipline. Default-secure policy. PR comments. Code Scanning ingestion. Auto-fixing the four common issues that have a single safe answer.

sherif

Cross-repo / monorepo lens. Sherif's value is comparing workflows across many repos under one org and surfacing inconsistency: same job, different timeout; same matrix, different runner; same checkout step, different version.

What it doesn't do: ship policy rules of its own. It tells you which workflows disagree; it does not say which one is right.

Use it for: standardising CI across an org once you've decided on a baseline.

octoscan

Security-first. Looks for untrusted-input injection patterns specifically (the ${{ github.event.* }} in shell context class), unpinned actions, missing top-level permissions, and similar hardening misses. Emits SARIF.

What it doesn't do: cost analysis, auto-fix, cache hints, retention policy, matrix sanity.

Use it for: security audit before a release. Quick check that your actions/checkout@... isn't shipping someone else's code.

How to combine them

None of these tools is a superset of the others. The cheapest composition that covers all four lenses is:

# syntax
actionlint

# cost + maintenance + auto-fix
npx ci-doctor --fix
npx ci-doctor --sarif > ci-doctor.sarif

# supply chain
npx pin-actions --check

# expression-level injection scanning
octoscan run

# cross-repo consistency, if you run an org
sherif --workspace .

Total runtime on a normal repo: under five seconds.

What I'd actually run in CI

In order, fail fast:

actionlint - syntax must be valid before policy makes sense.
npx pin-actions --check - cheap, supply chain.
npx ci-doctor --sarif > ci-doctor.sarif + codeql-action/upload-sarif - findings as PR annotations.
octoscan if your workflow accepts external input.

The first three are non-negotiable for any repo with public CI. The fourth is non-negotiable for any workflow that runs against PRs from forks.

Try without installing

If you want to see what ci-doctor would say about your workflow without installing anything, paste it at https://depmedicdev-byte.github.io/audit.html. Same engine, runs entirely in your browser, share the result by URL.

I priced the GitHub Actions workflows of 20 famous OSS projects. The results were ugly.

depmedicdev-byte — Mon, 27 Apr 2026 23:25:53 +0000

There is a class of "best practices for GitHub Actions" article that just lists the same five tips - cancel concurrent runs, set a timeout, cache your dependencies, pin actions to a SHA, narrow your matrix. Every one of those articles is correct, and almost none of them tell you how often even the best open source projects miss those exact things.

So I pulled the live workflow YAML out of .github/workflows for 20 well-known repositories, priced every job at GitHub's published per-minute rates, and ran a linter against the whole set. The data and the tools are public.

Headline numbers, all from public workflow YAML on main:

20 repos
229 workflows scanned
388 priced jobs (159 more were jobs running on self-hosted or unknown runners and excluded from cost math)
902 CI findings flagged by ci-doctor
About $51,000 of combined monthly spend assuming each job runs 30 times per day at 8 minutes per run

The interactive table is at https://depmedicdev-byte.github.io/benchmarks.html. A few of the per-repo numbers from the dataset:

Repo	$/run	Monthly @ 30/day	Findings
denoland/deno	$18.30	$16,473.60	84
facebook/react	$16.19	$14,572.80	87
vercel/next.js	(varies, see table)	(varies)	(varies)

(The full table has all 20 repos, sorted by monthly spend.)

What every project gets wrong

Across 902 findings, the distribution is heavy on a small number of issues:

Rule	Count
missing-timeout	364
missing-cache	113
pinned-action-sha	91
missing-permissions	80
artifact-no-retention	73
matrix-overcommit	52
missing-concurrency	52
deprecated-action	39
fetch-depth-zero	22
expensive-runner	12
wide-trigger	4

missing-timeout is the single biggest one. Out of 388 priced jobs, 364 of them are running without a timeout-minutes. A stuck job in CI does not exit on its own. It runs until GitHub kills it at 360 minutes, which is six hours of paid runner time, on top of whatever the job was actually trying to do.

missing-cache is the second. Most projects have one cached language tool (npm, or pip, or whatever) and then forget to cache the rest. Every pnpm install or bundle install or cargo build that runs without a cache costs you 1-3 paid minutes per job, every run.

missing-concurrency only shows up 52 times but it is the highest-leverage one to fix. Without a concurrency: block, a developer who pushes three quick fixes in a row triggers three full CI runs back to back. With a concurrency: block, the first two cancel and only the third runs. On an active PR this can cut your monthly spend in half.

How the data was generated

Three small open-source tools, all on npm:

# Audit a workflow:
npx ci-doctor .github/workflows/ci.yml

# Estimate the cost of a workflow:
npx gha-budget .github/workflows/ci.yml --runs-per-day 30 --minutes 8

# Pin every action in a workflow to a SHA:
npx pin-actions

The benchmark fetched workflow YAML for each repo via the GitHub REST API, then ran ci-doctor and gha-budget against every file. Each priced job was multiplied by 30 runs/day and 30 days/month. Self-hosted runners and runs-on values not in the GitHub price sheet were excluded from cost math but still scanned for findings. Code is in https://github.com/depmedicdev-byte if you want to reproduce it.

What you can do today

If you have a workflow you suspect is expensive, the fastest check is to paste the YAML into one of these:

https://depmedicdev-byte.github.io/audit.html - paste, get findings, no install
https://depmedicdev-byte.github.io/budget.html - paste, get $/run and monthly projection

Both run entirely in your browser. They share findings and totals via URL hash so you can send a teammate a link.

What I'd actually do

If I had to fix one thing per repo for maximum dollar impact, the order would be:

Add concurrency: { group: ${{ github.workflow }}-${{ github.ref }}, cancel-in-progress: true } to every PR-triggered workflow.
Add timeout-minutes: 15 (or whatever your real p99 is) to every job.
Cache whatever your install step is downloading. actions/cache for ad-hoc dirs, the official setup actions for language tools.
Pin every uses: to a full commit SHA. This is a security move more than a cost move, but the same pin-actions CLI handles it.

Those four changes alone, applied across the 20 projects in the dataset, would cut the combined monthly spend roughly in half. The longer set of patterns (60+) is in the Cut Your CI Bill cookbook but you do not need it to fix the top three.

Re-runs and updates

The dataset will be re-run monthly. If you want a specific repo added, open an issue on any of the tool repos and I will include it.