← FinOpsAid blog

How good are we at this, really? A maturity model for GitHub cost management

"Are we managing GitHub spend well?" isn't a question a dollar figure can answer. Crawl, walk, run — what each stage of FinOps maturity actually looks like on GitHub, how to place yourself honestly, and what moving up one stage costs you.

There's a question that tends to follow the first serious GitHub cost review, and it isn't about a number. It's are we actually good at this? Someone has just seen a total they didn't expect, and what they want to know is whether the organization has a practice or a panic.

No dollar figure answers that. A low bill can mean discipline or it can mean you're small. A high bill can mean waste or it can mean you're shipping. Capability is a separate axis from spend, and the honest way to measure it is a maturity model: not a score out of a hundred, but a description of what you can currently do — and, more usefully, what you can't.

Why a maturity model beats a score

The FinOps Foundation frames practice maturity as crawl, walk, run, and the framing earns its keep because it's descriptive rather than aspirational. Each stage is defined by a capability you either have or don't. That makes self-assessment falsifiable, which a score never is.

It also sets expectations correctly. Crawl is not a failing grade. Most organizations that have never metered GitHub are at crawl on every dimension, and the correct response is to do crawl well before reaching for anything else. Attempting chargeback before you can attribute a dollar to a team is how these programs die — you ship a number engineering can immediately disprove, and you don't get a second hearing.

Crawl: you can see the total, and you know when it changed

At crawl, the platform is no longer opaque. You know what GitHub cost last month, you know roughly what it'll cost this month, and someone would notice a large move within days rather than at renewal.

Concretely, crawl means: the bill is broken out by product — seats, Actions, Codespaces, storage, packages, AI — rather than sitting as a single line. Someone owns looking at it on a schedule. Historical months are retained, so you can say "this is up from" instead of just "this is". And you've internalised the one distinction that everything else depends on, which is that a usage signal is not a dollar.

Most orgs think they're past this stage. Test it with one question: if the bill jumped 30% next month, how long would it take you to say which product caused it? If the answer is "we'd export a CSV and have a look", you're at crawl. That's fine. It's also where the biggest and cheapest wins live, because idle seats and forgotten workflows don't require maturity to fix, only sight.

Walk: you can attribute it, and there are budgets to breach

Walk is where cost stops being an org-level fact and starts having owners. The capability that defines it is attribution: you can put a defensible share of spend next to a team, a department, or a repository, and you can explain how you got there.

That "explain how" is load-bearing. At walk you know which of your numbers are billed and which are modeled, and you say so. You've picked an allocation rule for the surfaces GitHub doesn't attribute for you, and it's written down. This is showback, and it precedes chargeback by a long way — the point of the first year is agreeing the numbers are fair, not moving money between cost centres.

Walk also introduces a threshold. A budget with no consequence is a spreadsheet, but a budget with a defined owner and a defined response is a control. You don't need automated enforcement yet. You need someone who gets told, and knows what to do when they are.

Run: cost is an input to engineering decisions

At run, nobody is chasing the bill, because the bill is expected. Forecasts are close enough to be boring. Variance gets investigated because it's variance, not because it's large.

The distinguishing capabilities are unit economics and anomaly detection. You track cost per active developer and its siblings, so growth in absolute spend is legible rather than alarming — a bill that rose 20% while the unit cost fell is a healthy quarter, and at run you can say that in one sentence. Deviations surface on their own instead of waiting for a human to notice a shape in a chart.

The cultural marker matters more than the technical one. At run, an engineer proposing a nightly matrix build across thirty repos knows the approximate cost before the pull request, and includes it. Cost has become a design constraint like latency or security, owned by the people who create it. That's the actual destination, and no tool gets you there by itself.

Place yourself at your weakest dimension, not your best

The common self-assessment error is to grade on the best-performing corner of the org. One team has beautiful Actions hygiene, so the org claims walk. It doesn't work that way — maturity is the level you can sustain across the whole platform, and the honest answer is usually one stage lower than the flattering one.

Assess it dimension by dimension. Visibility, attribution, budgeting, optimization, forecasting, culture. Most organizations land uneven: strong visibility, no attribution, no forecast. That unevenness is the finding. It tells you the next move, which is almost always to raise the lowest dimension rather than to polish the highest.

Moving up one stage

• Name the dimension you're worst at. Not the one that's most interesting to fix.
• Pick the single capability that defines the next stage for it. One. Attribution, or a budget with an owner, or a unit economic.
• Give it a person and a cadence. Capability that depends on someone remembering isn't capability.
• Write down what's modeled. Every stage above crawl depends on people trusting your numbers, and trust comes from labelled uncertainty, not from confident-looking precision.
• Re-assess quarterly, honestly. Maturity regresses when the person who cared changes role. That's normal, and worth catching.

None of this requires a big program. It requires being able to say which stage you're at without flinching, and then moving one dimension.

FinOpsAid scores this for you: the Overview dashboard carries a maturity assessment across those dimensions alongside the spend it's judging, so the capability question and the cost question sit on the same screen — with every modeled figure flagged and stamped with the sync it came from.

Curious where your organization actually lands? Connect your GitHub org — read-only and free during beta — or explore the demo dashboard first.

Frequently asked questions

What are the stages of FinOps maturity for GitHub?

Crawl means you can see the total and know when it changed. Walk means you can attribute it to teams and there are budgets that can be breached. Run means cost is an input to engineering decisions before they are made, rather than a report about decisions already taken.

Why use a maturity model instead of a score?

Because a score compresses everything into one number that hides where the actual gap is. A stage description tells you what specifically is missing and what the next concrete step is, which a percentage never does.

How do I know which FinOps stage we are at?

Place yourself at your weakest dimension, not your best. An organization with excellent visibility and no attribution is at crawl, not walk — the missing capability is what limits what you can actually do, and averaging over your strengths just flatters the assessment.