FinOps for GitHub
GitHub stopped being a subscription. Nobody updated the budget.
Short answer
FinOps for GitHub means treating GitHub as the metered cloud platform it now is: Copilot per seat plus credits, Actions per minute, Codespaces per core-hour, storage per gigabyte. The discipline is the same one you already apply to AWS or Azure — inform, optimize, operate — applied to a bill that moves on its own and that nobody owns.
The bill moves now, and the org chart hasn't caught up
For most of its life GitHub was a predictable line item: a per-seat subscription renewed once a year and never thought about again. That GitHub is gone. Today it meters six things independently, several of them driven by decisions individual engineers make without knowing there is a price attached.
The organisational consequence is the real problem. Cloud spend has owners, review meetings and a discipline around it. GitHub spend, in most companies, is still filed under 'software' and reviewed at renewal — by which point the year has already happened.
The principle everything else rests on
GitHub gives you two different kinds of number and they are not interchangeable. Usage signals — a seat's last-activity timestamp, minutes consumed, a daily per-user credit hint — arrive fast and describe behaviour. Billed amounts arrive from the billing API, lag the signals by a few days by design, and are what finance will actually be invoiced. Merge the two and you get a dashboard that is confidently wrong. Keep them apart, anchor the signal to the billed total, and show the gap.
This sounds pedantic until the first time a team is charged for something a dashboard estimated. Meter the signal, anchor it to the billed truth, show the gap, and label every estimate as an estimate. It is the difference between a number you can defend in a budget meeting and one you cannot.
The six meters under one line item
- Copilot seats
- Per assigned user. Fixed, forecastable, and the easiest place to waste money invisibly.
- AI credits
- Per unit of metered consumption above an allowance, at the serving model's rate.
- Actions minutes
- Per minute, at rates that differ by runner OS and size. Concentrated in a handful of workflows.
- Codespaces
- Per core-hour. Idle and oversized instances are the standing waste.
- Storage & packages
- Per gigabyte, accumulating monotonically until someone sets retention.
- Self-hosted runners
- On your cloud bill, not GitHub's. Modeled from your own rates — always an estimate.
Crawl, walk, run
Crawl is visibility: one place where all six meters are visible over a period longer than the vendor's retention window. Most organizations are here and think they are further, because a dashboard exists.
Walk is attribution: each meter mapped to an owning team, with the unallocated share visible and shrinking. This is where the practice starts changing behaviour, because a number with an owner is a number someone acts on.
Run is control: budgets per team, alerts on variance rather than on totals, forecasts that get compared against outcomes, and unit economics that survive a headcount change. Very few organizations run GitHub spend at this level, and the ones that do got there by staying at crawl until it was genuinely solid.
The artifacts that make it real
A practice is visible in what it produces. A monthly report an executive actually reads. Budgets with thresholds someone chose. Alerts that fire rarely enough that people still read them. A per-team cost that teams no longer dispute. And a reconciliation between metered usage and billed dollars that is shown rather than smoothed away.
FinOpsAid exists to produce those artifacts from GitHub's own data — nightly snapshots into a versioned warehouse where history is never overwritten, attributed to teams, forecast, and reconciled against the billing API. FinOpsAid connects through a GitHub App with read-only scopes. It changes no seats, edits no permissions, pushes no code, and never stores your source. Because only Read is granted, writing back to GitHub is not a policy we promise — it is technically impossible.
FAQ
Frequently asked questions
What is FinOps for GitHub?
It is the practice of managing GitHub as metered cloud spend rather than a fixed subscription — informing stakeholders with one reconciled number, optimising seats, workflows and storage in order of return, and operating a recurring review cadence with per-team ownership. The framework is the standard FinOps loop applied to six independent meters.
Why isn't GitHub in our cloud cost management tool?
Because cloud cost platforms ingest AWS, Azure and GCP billing exports, and GitHub is not one of them. It behaves exactly like cloud spend — metered, variable, driven by engineering decisions — but arrives through a different billing system entirely, so it sits outside the tooling and the review cadence built around those exports.
Where should we start with GitHub FinOps?
Visibility over a full budget cycle, before any optimisation. Most organizations skip to cutting costs using a rolling window shorter than the period they are being asked to explain. Get all six meters visible with retained history first; the levers are obvious once you can see which meter is actually moving.
How is this different from GitHub's own billing page?
GitHub's billing views show what you are charged, at the account level, over a retention window shorter than an annual cycle, with no team or repository dimension on most meters. FinOps needs attributed cost over retained history, reconciled against those charges — which means keeping your own snapshots and building the ownership mapping yourself.
Try it
See these numbers for your own org
Connect your organization read-only and FinOpsAid meters it nightly — seats, credits, minutes, Codespaces and storage, attributed to teams and reconciled against your billing API. Every modeled figure is labelled an estimate, with the date it was computed.