FinOps KPIs: The Metrics That Actually Change a Decision
Most FinOps KPI lists are inventories. Twenty-seven metrics, each with a formula, none with a reason. The test that matters is simpler: if no plausible reading of a number would make you do anything differently, it isn't a KPI — it's a statistic.
These ten pass that test. They're grouped by the ladder the rest of this site uses — measure, optimise, govern, then prove the return — because the order matters. A forecast built on unallocated spend is a guess with a chart attached.
Where these come from. These are the metrics we compute in our own assessment engines across Azure, AWS and Google Cloud, plus the ones we've watched teams mis-read often enough to write down. Thresholds are stated as working bands, not industry benchmarks — published FinOps benchmarks vary enormously by workload mix, and a "good" commitment coverage for steady infrastructure is a bad one for bursty batch. Treat them as starting points to argue with.
Measure
1. Unallocated spend
Formula: spend with no identifiable owner ÷ total spend.
Working band: under 5% is a functioning model; under 1% is excellent; above 20% and most of your cost conversations are guesses.
This is the foundation, and it's first for a reason: forecasting, chargeback and unit economics are all built on top of it. Fix this before buying anything that promises the others.
How it lies: measure it against total spend, not against taggable resources. The second version quietly excludes shared costs — NAT, egress, support, licensing — which are precisely the ones that are hard to allocate. A team reporting 3% on taggable resources can easily be at 25% overall.
2. Tag or label coverage
Formula: resources carrying every required key ÷ all resources.
Working band: 95%+ on new resources; treat legacy separately or you'll never see progress.
How it lies: coverage counts presence, not correctness. A tag reading owner: platform-team on a resource that platform disbanded last year is 100% covered and 0% useful. Sample for accuracy periodically — coverage alone trends toward a comfortable lie. See a tagging strategy that works.
Optimise
3. Commitment coverage and 4. commitment utilisation
Formulas: coverage = spend covered by a commitment ÷ eligible spend. Utilisation = commitment hours used ÷ commitment hours purchased.
Working band: 70–85% coverage on steady workloads, with utilisation above 95%.
These are two numbers and they must be read together — this is the single most common commitment mistake we see. High coverage with low utilisation means you over-bought: you're paying for reservations nothing is using, which is worse than paying on demand. Low coverage with high utilisation means there's money on the table.
How it lies: quoting coverage alone. It sounds like thoroughness and can be describing waste. Deep-dive per cloud: Azure, AWS, Google Cloud.
5. Addressable waste
Formula: annualised cost of findings you could act on this quarter ÷ total spend.
Working band: a first sweep commonly surfaces 15–30%; a mature estate holds under 5%.
How it lies: "addressable" does a lot of work. A finding nobody is allowed to action isn't addressable, it's a grievance. Price findings from the actual bill rather than list rates, and exclude anything blocked by a dependency you can't move.
6. Realised savings (not identified)
Formula: spend reduction visible in the bill, measured against the pre-change run rate.
The gap between identified and realised is the most honest measure of whether your FinOps practice functions. Identified savings measures intentions; realised savings measures money.
How it lies: savings reported as the sum of every recommendation ever generated. Recommendations double-count constantly — rightsize a VM and buy a reservation for it, and two tools will each claim the full saving. Reconcile against the invoice or don't report the number.
Govern
7. Time to detect a cost anomaly
Formula: hours from first anomalous spend to a human being alerted.
Working band: under 24 hours. Caught on day two, a spike costs two days; found on next month's invoice, it cost thirty.
How it lies: it measures detection, not response. Pair it with time-to-resolve, or you'll optimise for alerts that nobody acts on. See cross-cloud anomaly detection.
8. Forecast accuracy
Formula: |actual − forecast| ÷ actual, per month.
Working band: within 5% at one month out; within 10–15% at a quarter.
How it lies: accuracy improves beautifully if you forecast conservatively and everyone learns to pad. Track signed error, not absolute — persistent over-forecasting is a different disease from noise, and the absolute value hides it.
9. Budget variance
Formula: actual − budget, by owner, with the driver noted.
How it lies: variance without a driver note is theatre. "Marketing is 12% over" starts an argument; "Marketing is 12% over because the campaign data pipeline ran daily instead of weekly" starts a fix. See investigating a bill increase.
Prove the return
10. Cost per unit
Formula: attributable cloud cost ÷ the thing your business counts — customer, tenant, transaction, or successful AI output.
This is the only metric on the list a CFO will recognise without translation, and the only one that survives growth. Total spend rising is not a problem if cost per customer is falling.
How it lies: the denominator moves. Change how you count active customers and the trend line changes with it, so version the definition alongside the number. Detail in cloud unit economics, and for AI workloads cost per successful output — where retries mean the naive per-call figure understates reality.
The metric to be most careful with
Total cloud spend, in isolation. It's the number leadership asks for and the easiest to misread. Spend falls when you remove waste — and also when you ship less, lose customers, or defer work that returns at a premium.
Always pair it with a unit metric. If total spend falls while cost per customer rises, the business got smaller, not more efficient. That sentence has rescued more quarterly reviews than any dashboard.
At a glance
| KPI | Working band | How it lies |
|---|---|---|
| Unallocated spend | <5% | Measured against taggable, not total |
| Tag coverage | 95%+ on new | Counts presence, not correctness |
| Commitment coverage | 70–85% | Quoted without utilisation |
| Commitment utilisation | >95% | Hidden behind a good coverage number |
| Addressable waste | <5% when mature | Includes findings nobody may action |
| Realised savings | Tracks identified | Double-counted across tools |
| Time to detect | <24h | Ignores whether anyone responded |
| Forecast accuracy | ±5% at 1 month | Absolute error hides padding |
| Budget variance | Explained | A number with no driver note |
| Cost per unit | Falling | The denominator quietly changes |
How many should you track?
Fewer than you think. Five reviewed monthly beats twenty-seven on a dashboard nobody opens. If you're starting from nothing, take unallocated spend, commitment coverage with utilisation, and realised savings — then add a unit metric as soon as you can define the denominator.
Want these measured rather than estimated? The CloudFinOpsKit assessment computes allocation coverage, commitment coverage and utilisation, addressable waste priced from your real bill, and a 0–100 maturity score on the Crawl / Walk / Run model — in one read-only run, from $40. It won't track them over time; that's a platform's job, and we'd rather say so.
FAQ
What are the most important FinOps KPIs?
If you track only three: unallocated spend, because nothing downstream works without allocation; commitment coverage paired with utilisation, because the two together are the only honest read on your rate; and realised savings, because identified savings is a number about intentions rather than money. Everything else is refinement on those.
What is a good unallocated spend percentage?
Under 5% is a working allocation model, and under 1% is excellent. Above 20% means most cost conversations are guesses, and it is the first thing to fix because forecasting, chargeback and unit economics are all built on top of it. Measure it as a share of total spend that cannot be attributed to an owner, not as a share of taggable resources, which quietly excludes the shared costs that are hardest to allocate.
How many FinOps KPIs should a team track?
Fewer than most lists suggest. A KPI earns its place by changing a decision — if no plausible reading of it would make you do anything differently, it is a statistic, not a KPI. Most teams are better served by five metrics reviewed monthly than twenty-seven on a dashboard nobody opens.
Is reducing total cloud spend a good FinOps KPI?
On its own, no — it is the most commonly misread metric in FinOps. Spend can fall because you removed waste, or because you shipped less, lost customers, or deferred work that will cost more later. Pair it with a unit metric such as cost per customer or cost per transaction; if total spend falls while unit cost rises, the business got smaller rather than more efficient.
Related reading: how to choose a FinOps tool · cloud unit economics · a cloud cost governance framework · what is FOCUS? · showback & chargeback · the Cloud Center of Excellence · forecasting cloud spend