DEV Community

Cover image for GitHub Actions won't tell you your CI is getting worse. I built a zero-dep CLI that does.
benjamin
benjamin

Posted on

GitHub Actions won't tell you your CI is getting worse. I built a zero-dep CLI that does.

#showdev #cli #devops #opensource

GitHub Actions shows you one run at a time. Green check, red X, green check, green check, red X. You scroll the list, you re-run the flaky one, you move on. Nobody's asking the question that actually matters: is this getting better or worse?

"I calculated how much my CI failures actually cost. Curious what your pipeline success rate looks like — has anyone else tracked the actual wasted compute time over time?"

That's a real question from someone who did the math by hand and found their failures were burning a real chunk of their compute budget. The replies were the same story you'd expect: heavyweight CI platforms have their own dashboards for this, but nobody had a lightweight, local way to just... track it.

So I built citrend: pull your GitHub Actions run history into a local file, get a trend.

npx citrend sync --repo owner/name
npx citrend report --repo owner/name
Enter fullscreen mode Exit fullscreen mode

What it actually shows you 

$ citrend report --repo acme/widgets

acme/widgets — 812 run(s) (2 in progress)

  success rate:    87.4%  (699/800 settled, 12 skipped)
  wasted runs:     101 (12.6%)
  total compute:   118h 42m
  wasted compute:  14h 6m

  weekly trend (oldest → newest):
    2026-06-05  91.2% success, 8 wasted (58m)
    2026-06-12  88.0% success, 11 wasted (1h 22m)
    2026-06-19  79.4% success, 22 wasted (3h 8m)
    2026-06-26  84.1% success, 15 wasted (2h 1m)
Enter fullscreen mode Exit fullscreen mode

That weekly column is the entire point. A single gh run list will never show you that week 3 was a cliff — you'd have to notice it got annoying to work in, which is a much slower and much less precise signal than a number going from 91% to 79%.

How it works

sync pulls your workflow run history from the GitHub REST API and caches it locally (deduped by run id, so you can run it on a schedule without piling up duplicates). report reads that cache — no network call — and computes:

  • Success rate, over settled runs only (still-running runs don't count either way until they conclude, and skipped runs are excluded from the denominator since they're not a pass/fail outcome).
  • "Wasted" runs and compute — anything that settled and wasn't a success or a skip: failures, cancellations, timeouts. "Compute" here is wall-clock run duration from the Actions API, a solid proxy for burned runner time, not an exact billed-minutes figure.
  • A weekly trend, so a slow decline (or a sudden cliff) is visible instead of buried in a scrolling run list.

Install 

npx citrend sync --repo owner/name --token $GITHUB_TOKEN   # token optional for public repos, raises the 60/hr rate limit
npx citrend report --repo owner/name --weeks 8

pip install citrend   # Python build, same commands, shares the same local cache format
Enter fullscreen mode Exit fullscreen mode

Zero dependencies in either language — just the standard library talking to api.github.com. History lives at ~/.citrend/<owner>__<repo>/, not committed to the repo it's tracking (it's a cache of data GitHub already has, not something worth diffing in git).

Does your team track this anywhere already — a scheduled job dumping stats into a spreadsheet, a Grafana panel someone built once and nobody looks at? Curious what's actually surviving in practice versus what gets built and abandoned.

Top comments (0)