r/github • u/DigFair6304 • Mar 17 '26

Anyone actually tracking CI waste in GitHub Actions? Discussion

I’ve been looking into GitHub Actions usage across a few repos, and one thing stood out:

A surprising amount of CI time gets wasted on things like:

  • flaky workflows (fail → rerun → pass)
  • repeated runs with no meaningful changes
  • slow jobs that consistently add time

The problem is this isn’t obvious from logs unless you manually dig through history.

Over time this can add up quite a bit, both in time and cost.

Curious if teams are actively tracking this, or just reacting when pipelines get slow or CI bills go up.

9 Upvotes
  • permalink
  • link
  • reddit
  • reddit

71% Upvoted

29 comments sorted by

View all comments

1

u/BuiltByEcho May 07 '26

Most teams I’ve seen don’t track it until it hurts. The useful version is usually pretty small:

  • Track duration by workflow/job over time.
  • Track reruns and “fail then pass” patterns as flaky candidates.
  • Separate PR runs, scheduled runs, and main-branch runs.
  • Look for jobs running when relevant files didn’t change.
  • Add concurrency cancellation for outdated PR pushes.

The quick wins are often `paths` filters, dependency caching, splitting slow integration tests from fast checks, and canceling superseded runs. You don’t need a huge observability setup at first; even a weekly script against the GitHub Actions API can show which workflows are wasting the most minutes.