← FinOpsAid blog

What can we actually cut, and how confident are you? GitHub savings you can defend

Most savings numbers sum everything technically reclaimable. How to split GitHub savings into certain, conditional and modeled — and rank by what converts.

Show an engineering leader a dashboard with "potential savings: $84,000/yr" on it and watch what happens. The first question is never how do we get it. It's is that real — and they're right to ask, because that number is usually the sum of every theoretically reclaimable dollar the tool could find, which is a very different quantity from money that will ever leave the budget.

The gap between those two is where cost programs lose credibility. Claim a big number, deliver a fraction of it, and the next number you present gets discounted before you finish the sentence. The fix isn't to be pessimistic. It's to stop reporting one number when you actually have three different kinds of saving.

Three kinds, and only one is certain

Certain. The resource is billed, provably unused, and reclaiming it changes the invoice next cycle. A Copilot seat assigned to someone who left. A Codespace that hasn't been opened in two months. There's no modeling here — GitHub bills these per unit, the unit is identifiable, and the arithmetic is subtraction.

Conditional. The saving is real but depends on a decision someone has to make and live with. Dropping a nightly build to weekdays. Moving a workflow to a smaller runner. Shortening artifact retention. You can size these accurately; what you can't do is book them, because "we could" is not "we will" and the team that owns the workflow might have a reason you haven't heard.

Modeled. The saving depends on an allocation or a projection rather than a billed line. Most per-repo Copilot attribution, self-hosted runner cost, anything expressed as "if usage patterns hold." Legitimate for prioritisation and dangerous as a commitment.

Summing all three into one headline is how you end up defending a number you can't deliver. Report them as three, and the conversation stays about the work instead of about your credibility.

The confidence label is the product

A recommendation without a confidence label makes the reader do the risk assessment themselves, and they'll do it by discounting everything equally. Attaching confidence explicitly is what lets a finance partner treat the certain bucket as bankable and the conditional bucket as a pipeline.

Confidence should come from the evidence, not from a feeling. Ask what the claim rests on. Is the resource billed per unit, or allocated by a rule you chose? Is "unused" measured over a window long enough to survive someone's holiday? Would reclaiming it need a human decision, and whose? A recommendation that says "seat inactive for 74 days, billed at the standard rate, reclaimable without consulting anyone" is a different object from "this repo appears to over-consume runner minutes relative to peers," and flattening them into one list is the mistake.

Where the money actually is on GitHub

The distribution is fairly consistent across organizations, and it's not where people expect.

Licence waste is almost always the biggest certain bucket, and the easiest — idle Copilot seats are billed per assignment regardless of use, so reclaiming them is pure margin with no engineering decision attached. Idle and oversized Codespaces come next: a dev environment nobody has opened in weeks is billed while it exists, and an environment provisioned four sizes larger than its workload is billed for the difference forever.

Compute is the biggest conditional bucket. A handful of workflows account for most Actions minutes, so the money is concentrated and sizeable — but every fix is a trade against build time or coverage, and it belongs to a team. Storage and artifact retention sit alongside it: real money, trivially adjustable, but somebody has to say what retention period is acceptable.

Governance savings are the quiet ones. Dormant accounts, duplicated tooling, forgotten runner fleets. Individually small, collectively not, and they usually come with a security dividend attached.

This split maps onto the FinOps Foundation's distinction between optimization you can automate and optimization that requires a workload decision — the first is an operational task, the second is a negotiation, and treating them as one list is what stalls both.

Rank by realisable, not by size

The instinct is to sort recommendations by annual value. It produces a list that starts with the hardest thing on it.

A better ranking multiplies value by the probability you'll actually do it, which in practice means weighting by whether a decision is required and how many people have to agree. A $4,000 saving nobody has to approve beats a $30,000 saving that needs three teams to change their build strategy — not because it's bigger, but because it will happen this month and the other one has been on the list since February.

There's a compounding reason too. Certain savings delivered quickly are what buy you the standing to propose the conditional ones. Lead with the reclaim, then spend that credibility on the trade-offs.

The savings that come back

Any saving that isn't attached to a control reappears. Reclaim forty seats today and onboarding will re-assign them by the next quarter unless something changed about how seats get granted. Shrink an oversized Codespace and the next person to clone that template gets the old size.

So track realised savings separately from identified ones, and re-run the audit on a cadence rather than treating it as a project. The number worth reporting to finance isn't what you found — it's what stayed found.

A savings review that holds up

• Split the list three ways before anyone sees a total. Certain, conditional, modeled.
• Attach the evidence, not just a figure. What's billed, what's measured, over what window.
• Rank by realisable value. Decisions required is the variable that predicts whether it happens.
• Name an owner for every conditional item. Otherwise it's a wish, and it will age like one.
• Report realised versus identified. The delta between them is the honest measure of the programme.
• Re-run it monthly. Waste regenerates; a one-off audit decays within a quarter.

Do that and "potential savings" stops being a number people squint at and becomes a pipeline with a conversion rate you can quote.

FinOpsAid is built around exactly this split: Savings surfaces licence, compute, CI-efficiency and governance recommendations with an estimated annual value and an explicit confidence label on each one, modeled figures flagged as modeled, and the evidence behind every recommendation shown next to it rather than buried in a methodology note.

Frequently asked questions

Why can't I trust the savings number in a cost tool?

Because most sum everything technically reclaimable and present the total as if it were achievable. A figure that mixes an idle seat with a named owner and a speculative right-sizing exercise is not one number — it is two different kinds of claim added together.

How should savings be ranked?

By what will actually convert, not by size. A small certain saving with a named owner beats a large modeled one that needs a reorganisation, because delivering the first is what earns you permission to propose the second. Rank by realisable value and work down.

Why do the same savings keep reappearing?

Because cleanup is not prevention. Reclaiming today's idle seats or forgotten environments takes an afternoon; stopping them regenerating takes a policy — a retention period, a provisioning rule, a machine-type constraint. Without that, the same list is waiting for you next quarter.

Want to know which of your savings are bankable and which are a conversation? Connect your GitHub org — read-only and free during beta — or explore the demo dashboard first.