Cloud cost management
Your cloud cost tool cannot see GitHub.
Short answer
GitHub is metered, variable, and driven by engineering decisions — exactly like cloud spend — but it does not arrive through AWS, Azure or GCP billing exports, so cloud cost management platforms do not ingest it. The result is a growing, engineering-driven bill that sits outside the one process built specifically to manage growing, engineering-driven bills.
Why GitHub is invisible to cloud cost tools
Cloud cost management platforms are built around the billing exports the three hyperscalers publish. That is a reasonable design and it is why they work so well — until a service bills through a different system entirely.
GitHub does. Its meters live in GitHub's own billing platform, with their own APIs, their own retention behaviour and their own account structure. A CCM tool pointed at your cloud accounts will report your infrastructure to the cent and show nothing at all for the platform your engineers spend all day in.
It behaves exactly like cloud spend
Every property that makes cloud cost hard to manage is present. It is metered, so nobody approves a unit of it. It is variable, so last month is a weak predictor. It is driven by engineering decisions — a workflow trigger, a model choice, a runner size — made by people who cannot see the price. And it is shared, so it lands centrally and has to be attributed back.
That is the argument for treating it with the same discipline rather than as a software subscription: not because the vendor is a cloud, but because the cost has a cloud's shape.
The half that IS on your cloud bill
One part of GitHub spend does show up in your CCM tool, and it is usually misfiled. Self-hosted runners are your compute: EC2 instances, VM scale sets, GKE nodes, paid for by you whether or not a job is queued. Container registry egress, artifact storage you moved to your own buckets, and any agent infrastructure land there too.
So the accounting is split down the middle: some GitHub cost is on GitHub's invoice, some is on your cloud invoice under a tag that says 'ci', and neither view alone tells you what CI costs. FinOpsAid models the runner-fleet side from your own rates and labels it an estimate, because it is not a figure anyone bills you — presenting it as billed would conflate exactly what we exist to keep apart.
Fitting GitHub into a practice you already run
You do not need a second FinOps programme. You need GitHub in the one you have — same cadence, same owners, same report.
Practically: add GitHub's meters to the monthly review alongside the cloud accounts. Map GitHub teams to the same cost centers your cloud allocation already uses, so the two halves of the CI story can be added. Set budgets in GitHub's billing platform that match the thresholds you use elsewhere. And insist on the same evidentiary standard — billed is billed, modeled is modeled, and anything estimated says so.
What to ask before you buy anything
- Does it read the billing API, or only usage?
- Usage-only tools cannot reconcile. They will show you a confident total that never matches the invoice and cannot explain why.
- How long is history retained?
- If the answer matches the vendor's own retention window, you cannot do year-over-year — which is most of what a budget cycle asks for.
- How is per-team cost derived?
- Ask which meters are attributed exactly and which are modeled. A tool that will not distinguish them is asking you to defend its guesses as facts.
- What access does it need?
- Cost analysis needs metadata and metrics, not file contents. Read-only scopes should be sufficient, and if they are not, ask why.
FAQ
Frequently asked questions
Why doesn't our cloud cost tool show GitHub spend?
Cloud cost management platforms ingest AWS, Azure and GCP billing exports. GitHub bills through its own platform with its own APIs and account structure, so there is no export for those tools to read. The spend is real and behaves like cloud cost, but it sits entirely outside the process built around hyperscaler billing data.
Is GitHub spend part of cloud cost management?
It should be, by behaviour if not by vendor category. GitHub spend is metered, variable, generated by engineering decisions and shared across teams — every property that makes cloud cost hard to govern. Managing it under a different, slower process than your cloud spend is a structural gap, not a taxonomy question.
Do self-hosted runners show up in cloud cost tools?
Yes, but usually misfiled. Self-hosted runners are your own compute — instances, scale sets or nodes — so they appear on your cloud bill rather than GitHub's, frequently under a generic tag. That splits CI cost across two invoices, and neither one alone tells you what continuous integration actually costs.
How do we allocate GitHub cost to the same cost centers as cloud?
Map GitHub teams to the cost centers your cloud allocation already uses, rather than inventing a parallel structure. Attribute each GitHub meter to a team using its own key, then roll those teams up through the existing mapping — that way the GitHub half and the cloud half of CI cost can actually be added together.
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.