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 #devops #cli #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 (1)

Collapse
 
aldo_cve profile image
Aldo •

The 'boiling frog' problem for CI pipelines is incredibly real, and it's something we've wrestled with across several SaaS products. You rarely see a sudden 10-minute jump in build time; it's always a gradual creep of 10 seconds here, 30 seconds there, as new tests are added, dependencies grow, or more complex integrations get baked in. GitHub Actions' single-run view really does obscure that degradation.

The true cost isn't just the extra minutes waiting. It's the cumulative effect on developer flow and the insidious context switching. A pipeline that takes 5 minutes lets you stay in the zone for a quick review or a Slack message. One that drifts to 15 or 20 minutes forces you to switch tasks, lose focus, and then re-engage. That's a significant drag on productivity that often goes unmeasured until someone finally shouts about it.

We've explored everything from custom Grafana dashboards pulling build metrics via APIs to just running gh run list and trying to eyeball trends. The latter is obviously not scalable, and the former involves a non-trivial amount of setup and maintenance for what should be a core observability metric. A zero-dependency CLI that immediately surfaces those trends is a smart approach. It brings the data right to the developer's terminal, which is often where the initial curiosity about CI performance begins.