FinOps Severity Now Ranks Right-Sizing by Real Savings

A recommendations engine that flags idle resources, orphaned volumes, and right-sizing opportunities usually assigns severity by rule type: every idle-disk finding is “Medium,” every orphaned-snapshot finding is “Low,” regardless of what any individual finding is actually worth. That’s fast to build and easy to reason about in the abstract. It’s also wrong in a specific, costly way: a fixed label can’t distinguish a $40-a-month idle disk from a $40,000-a-month idle cluster, so both show up with the same urgency and the second one waits behind a queue of $40 findings that happened to load first.

FinOps is the practice of giving engineering, finance, and product teams shared, real-time visibility into cloud cost so spending decisions get made where the usage happens instead of after the bill arrives. A recommendations engine that ranks findings by dollar impact is one of the mechanisms that practice depends on: it only works if the ranking reflects real money, not just which rule happened to fire. ZopNight’s cost-saving recommendations, covering idle, orphaned, right-sizing, scheduling, and commitment or discount findings, now carry a severity that reflects what a finding is actually worth instead of which rule produced it.

Severity Now Tracks What You’d Save, Against Your Own Spend

The new score is driven mainly by projected savings, but not as a raw dollar figure. It’s measured against the account’s own cloud spend, so the same dollar amount produces a different severity depending on the size of the account it showed up in. A $2,000-a-month saving is a rounding error against a $3 million cloud bill and a serious finding against a $50,000 one. Scoring against the account’s own baseline is what makes “Critical” mean the same thing across two accounts that spend nothing alike.

The result is a Critical, High, Medium, or Low ranking you can work top-down and trust while doing it. Savings always drive that ranking: a bigger projected saving never sits below a smaller one, in either direction, regardless of anything else the engine knows about either finding.

Confidence and Waste Refine the Ranking, They Don’t Override It

Two more signals adjust the score without controlling it. Confidence reflects how sure the engine is that a finding is real, and waste ratio reflects how much of a resource is actually sitting unused. Both refine where a finding lands inside its band. Neither can move it into a different band on its own.

That distinction is deliberate. An easy shortcut would let a highly confident but low-value finding rank above an uncertain but expensive one, which would optimize the list for certainty instead of for dollars. The engine caps confidence’s weight so it can adjust a score without ever crossing a severity boundary by itself. Only the underlying savings number can do that.

This works when a finding has an actual dollar projection behind it. It breaks down for recommendation types that don’t carry a savings number at all, which is why the change is scoped specifically to cost-saving categories. Security, compliance, reliability, and other non-cost recommendations keep their existing severity untouched, because there’s no spend figure to score them against in the first place.

Changing How Severity Is Computed Means Reconciling What’s Already Open

A scoring engine change doesn’t just affect new findings. Every recommendation sitting open in an account was scored under the old rules, and leaving them there would mean two different severity systems coexisting silently in the same list. The fix ships with an admin rescore path that can recompute severity for a single org or every org at once, specifically to reconcile existing open recommendations after an engine change like this one.

Reconciling at that scale surfaced three separate failure modes that had to be closed before a rescore was safe to run. An account with no cost history yet could crash the scoring pass instead of skipping cleanly. A partial cost snapshot could mass-close recommendations that were still valid, mistaking incomplete data for zero savings. And a closed recommendation could silently reopen (“resurrect”) if a stale snapshot got re-processed after the fact.

None of these are edge cases you’d hit once and move on from. They’re exactly the failure modes a savings-driven severity model has to rule out, because the entire point of ranking by dollar impact collapses if the dollar figures underneath the ranking can’t be trusted at reconciliation time.