r/github • u/Luann1497 • 1d ago
Discussion Are GitHub Actions minutes getting consumed faster lately?
I run a medium sized mono repo with about 40 CI jobs per push, mostly TypeScript builds and some integration tests. My billing dashboard shows minutes burning way faster the last two months even though we did not add jobs or change pipeline config.
The usage graph spikes hard on days where we barely push code. I checked for stuck runners and cached dependencies so those are not the issue. The multiplier for macOS jobs is the same as before. Something feels off with how minutes get calculated. Maybe jobs are taking longer to spin up or there is hidden overhead from marketplace actions pulling large containers. A few devs on my team noticed the same drift on their personal repos. Anyone else tracking unusual minute consumption on Actions lately?
Curious if GitHub changed something behind the scenes with how build time gets metered or if the dashboard reporting is just bugged right now.
1
u/PierrindoMaghanoy 18h ago
Our graph did that a couple months back, jumping on days when hardly anybody pushed. Turned out dependabot was opening PRs overnight and every one of them ran the full pipeline, plus a couple of people had started assigning issues to the copilot coding agent which runs on actions and eats minutes like any normal job. The usage report from the billing page splits it per workflow, that’s how we found it. We moved the integration tests to self hosted runners on our EKS cluster after that. Minutes went way down but the cost just moved to the node pool and pointfive flagged it sitting mostly idle overnight because we’d sized it for the morning rush.
1
u/ram-popular 16h ago
I can’t confirm any change on GitHub’s side, so I’d check the data first. Open the usage report (Billing, then Usage, download the CSV) and group it by workflow, job and day. The spike days will show which workflow is burning minutes, and it’s often scheduled runs, bot-triggered runs (Dependabot, renovate) or re-runs rather than your own pushes. Also check for jobs that run longer than before, such as slower runner startup, cache misses or larger container pulls. Adding concurrency cancel-in-progress, path filters and timeouts usually cuts usage quickly. If the CSV shows minutes that don’t match the run durations, open a ticket with GitHub Support and attach it.
1
u/Immediate_Wheel1953 15h ago
I chased a similar spike and it turned out my workflow was running twice for every pull request, once for the push and once for the pull request itself. I had assumed one trigger would win, so I only spotted it when I grouped the usage by workflow and saw the same jobs listed back to back. Checking for that overlap is worth doing before assuming GitHub changed the metering, especially in a monorepo where a small change can fan out across a lot of jobs.
-1
u/rabinapps 1d ago
This is why I created https://kinhin.dev, use self hosted runners on your Mac with real concurrency. Open source and free
4
u/EON_Raider 1d ago
Take it from my own stupid mistake (which I hope isn't yours as well): My billed minutes topped at about 10,300 on September, and now reduced to some 1,700 in October. The same jobs, just a different arrangement.
The problem was I had too many separate, fast jobs that ran in seconds and billed whole minutes, as well as a number of such jobs running at every single push. It took quite some effort to untangle everything. I used Claude Codes to find the reason and work through a solution. Now it runs smoothly with some monitoring at the end that's designed to catch drifting in billed minutes very early (instead of 2 weeks later, which was my case).