Want to become a partner, click here to schedule time to talk with the team.
FinOps & Beyond is what engineering, finance, and IT leaders read to understand FinOps, and what it means for operating models, accountability, and spend decisions.
Table of Contents
General Tech Trends Analysis
Reactive FinOps: Where Cost Improvement Actually Starts
In last week’s newsletter, I stated “In the coming weeks, I’ll go deeper into specific actions and patterns that help drive real progress.” Through consistent and deliberate actions with conviction, you, as an Engineering, IT, or Finance leader can drive change and build trust.
Most leaders start FinOps conversations by focusing on where things should go, including topics such as:
Shift left
Embed cost into architecture and associated design
Define unit economics early.
I personally love these topics and they are all directionally correct. But it skips an important reality. Most organizations are not starting from a clean slate. They are starting from environments that already exist, are already scaled, and are already inefficient in ways that are both obvious and hard to fix.
So before talking about proactive FinOps, there is a more immediate question.
What do you do with the environment you already have?
The State Most Teams Are In
The 2026 data tells a different story than the one the industry has been telling itself.
Flexera's 2026 State of the Cloud report, released in March, found that wasted cloud spend rose to 29% — the first increase in five years. The cause appears to be AI. Cloud-based AI workloads surged faster than teams could wrap them in the cost controls that took years to build for traditional infrastructure. Brian Shannon, Chief Technology Officer at Flexera, summarized the implication in the report's announcement:
Cloud success in 2026 hinges on disciplined oversight, value measurement, and proactive AI governance.
The FinOps Foundation's State of FinOps 2026 — the sixth annual survey, 1,192 respondents representing $83 billion in annual cloud spend — documented the consequence. Managing AI costs is now cited as a priority by 98% of practitioners. AI cost management has leapt to the top of the priority list, alongside governance at scale, AI-driven efficiency, and expanded scope beyond cloud. Workload optimization and waste reduction — the #1 priority in 2025 — dropped meaningfully this year.
The industry has moved on to the new problem just as the old one has started regressing.
Deloitte's 2026 TMT Predictions add the scale. Inference is on track to account for two-thirds of all AI compute this year, most of it still running in data centers on chips worth north of $200 billion. Seventy-five percent of companies are expected to invest in Agentic AI in 2026 — another layer of autonomous, unpredictable spend on top of already crowded cost structures.
InformationWeek's 7 cloud computing trends for leaders to watch in 2026 captured the business tone:
Cloud cost pressures, combined with more general enterprise fiscal concerns such as stubbornly high borrowing rates, mean that FinOps will likely be at the heart of more boardroom conversations over the coming year.
The issue is not awareness. It is follow-through.
The Execution Gap
Better data is not producing better outcomes. That is the tension the industry is now sitting with.
InformationWeek framed the question sharply this month: is FinOps a genuine control discipline, or a placebo that lets CIOs feel organized while the cost base compounds underneath the dashboard?
The honest answer is that it is both. Where FinOps is deployed as a finance-led reporting tool — spend without ownership to act on it — it is a placebo. Where it is a cross-functional discipline with real engineering accountability, it is not.
The gap between those two versions of FinOps is where the 29% sits. That gap is the reactive FinOps problem.
Reactive Does Not Mean Inefficient
There is a tendency to treat reactive cost management as second-class.
It is not. Reactive FinOps is where inefficiencies are identified, ownership is established, and trust is built through execution. It is also where most of the immediate financial impact comes from.
Unused resources, over-provisioned systems, idle environments, poor lifecycle management, orphaned training jobs, stale GPU reservations. These are not theoretical. They are present in nearly every environment.
The challenge is not finding them. The challenge is fixing them.
Why Cleanup Efforts Fail
Most cleanup efforts fail for the same reasons.
They are treated as one-time initiatives. A cost optimization sprint happens, savings are realized, and the system regresses to the same waste line within two quarters.
They are not owned by engineering. FinOps or Finance identifies the issue, but Engineering is not accountable for resolution.
They are not integrated into execution workflows. Findings live in dashboards or reports, not in backlogs or sprint plans.
They lack prioritization. Everything is flagged as an opportunity, so nothing gets done.
The concrete moves to fix this — cadence, ownership model, throughput metrics — live in the Operator Playbook further down this issue.
But We Still Need to Move Left
The mistake is reading "reactive first" as "proactive later."
It is not sequential. The backlog is never clean, and in 2026 the AI-driven uptick in waste guarantees it will keep getting longer until the shift-left work actually lands.
The model is parallel, not sequential. Reactive work runs on a fixed cadence with engineering ownership. Shift-left begins as a thin wedge alongside it:
One architecture review that includes a cost section
One service team running unit economics against its roadmap
One tagging or allocation rule enforced at deploy time
One PRD template with a required cost-impact field
None of these solve the problem individually. Together, over time, they change what the reactive backlog looks like two years from now. (Note - More to come on this in next week’s newsletter)
Reactive work also produces the signal that makes proactive work accurate. Every recurring cleanup item points to something upstream that needs a design change. Teams that skip the reactive phase move left blind.
Start reactive. Begin shifting left in parallel. Let each inform the other.
The Role of Tools
Reactive-side tooling has matured. Vendors surface inefficiencies, automate specific optimizations, and increasingly route findings into engineering ticket systems rather than stopping at a dashboard.
These are valuable capabilities. They do not solve the core problem. Tools can tell you what to do. They do not ensure it gets done.
What Good Looks Like
A functioning reactive FinOps model does not eliminate inefficiencies. It creates a system where waste is continuously identified, actions consistently taken, and improvements compound over time.
All of it has to be in service of something.
The difference between reactive work that builds and reactive work that drifts is whether the organization has a KPI that the cost work is pointed at. Cost per customer. Cost per transaction. Gross margin by product line. Infrastructure spend as a percent of revenue. The exact metric depends on the business. What matters is that one exists, is agreed upon at the executive level, and that every optimization is evaluated against it.
With a north star, the backlog prioritizes itself. Savings in isolation are noise. Savings against the north star are signal.
Without one, reactive FinOps runs on vibes — every optimization defended by its local dollar impact, nothing aggregating, the quarterly narrative to finance collapsing under its own inconsistency.
Set the north star before you set the cadence. Everything else is work, not strategy.
Where Reactive Becomes Proactive
Reactive FinOps is often viewed as cleanup work. And it is. But it is also the foundation. It is where organizations establish ownership, prove execution capability, and build the muscle that makes everything downstream possible.
Reactive work tells you where waste comes from. That intelligence is the input to the other half of the system — ADRs that treat cost as an architectural criterion, PRDs that ship with a cost-impact field, unit economics that shape design before it ships.
Because if you cannot clean up your current environment, you will not control the next one.
Next week: the proactive side. ADRs, PRDs, and cost-as-a-first-class design criterion — how to stop the backlog from being regenerated faster than you can clear it. The concrete reactive framework — cadence, ownership, and throughput metrics — is in the Operator Playbook later in this issue.
Want a particular topic to be covered. Want to share what you like or don’t like. Leave a voice message using Voicebox AI
FinOps Signal
Structural Trend Quick Takeaway
Track Recurrence, Not Just Savings
Most reactive FinOps programs measure savings. Almost none measure whether the savings stuck.
That gap has a name: recurrence rate — the percentage of optimization wins that reappear on the backlog within two to four quarters. Without it, you cannot tell the difference between a working reactive program and a cleanup loop that rediscovers the same waste every quarter.
Two 2026 pieces frame the problem directly.
CloudZero, in How To Reduce Cloud Costs in 2026, puts it plainly:
"One-time rightsizing exercises, tagging mandates without enforcement or dashboards nobody acts on, always produce short-term savings followed by a reliable return to baseline."
Return to baseline is exactly what recurrence rate measures. And from a different vantage — Ramp's 15 FinOps KPIs You Should Track in 2026:
"A one-time analysis may find savings, but those gains will disappear without consistent follow-up."
How to Define It
Recurrence rate is a simple ratio. Numerator: optimization tickets closed this quarter where the same workload, resource type, and remediation pattern also appeared on a closed ticket in either of the prior two quarters. Denominator: total optimization tickets closed this quarter.
Most teams do not need a more sophisticated formula than that. What they need is any formula at all. Start with workload identifier plus remediation type. Rightsizing the same Kubernetes cluster three quarters running is a distinct problem from idle-cleanup recurring on the same cluster — and both are distinct from an anomaly that recurs because the autoscaler was never fixed.
The AI Twist
Recurrence matters more in 2026 than it did in 2024, and the reason is AI.
Traditional cloud workloads regenerate waste slowly — utilization drifts, ownership rots, commitment ladders expire. AI workloads regenerate waste fast. Training jobs launch at the wrong instance class, inference endpoints over-scale and stay that way, GPU reservations get held by experiments that finished three months ago. The Flexera 2026 uptick in wasted cloud spend is not a mystery — it is a recurrence problem running at AI velocity, against a cadence built for traditional workload speeds.
If your recurrence tracking is still quarterly, your AI waste will outrun it.
The Diagnostic Threshold
A low recurrence rate — under 20% — means the reactive program is working. Items get cleaned and stay clean.
A high recurrence rate — above 40% — is not a reactive problem at all. It is an architectural one. No amount of cadence, ownership clarity, or tooling fixes a system that regenerates the same waste faster than it can be cleared. When recurrence runs high, the cost is being generated by a design decision upstream. The right response is an ADR, not another rightsizing sprint.
Most teams have no idea where they sit on this spectrum. The measurement itself is the first move.
Savings without recurrence tracking is a vanity metric. Savings against a recurrence rate that is trending down is progress.
If you do not know your team's recurrence rate, you do not know if your reactive FinOps works.
Want a particular topic to be covered. Want to share what you like or don’t like. Leave a voice message using Voicebox AI
FinOps Industry
News or Market Updates - Open Source
Open Source Tools
This week, I wanted to share a list of 10 open source tools found on Github that can support your day-to-day work. These tools can be applied across both reactive cleanup efforts and proactive cost improvement initiatives.
(Note - There may be other tools and solutions that are open source and free to access outside of Github, but focused here for this list.)
1. Infracost — 12,251 stars
https://github.com/infracost/infracost
Open-source FinOps tooling that shows Terraform cloud cost estimates in PRs, CI/CD, and developer workflows before infrastructure changes are deployed.
2. OpenCost — 6,480 stars
https://github.com/opencost/opencost
OpenCost provides Kubernetes and multi-cloud cost visibility, allocation, and monitoring so teams can understand where infrastructure spend is going.
3. Cloud Custodian — 5,958 stars
https://github.com/cloud-custodian/cloud-custodian
Cloud Custodian is a policy engine for governance, security, and cost optimization that helps teams automatically find and act on wasteful or noncompliant cloud resources.
4. ec2instances.info — 5,700 stars
https://github.com/vantage-sh/ec2instances.info
ec2instances.info is a searchable comparison site for AWS instance types and pricing that helps FinOps and engineering teams make more cost-aware infrastructure choices.
5. gocrane/crane — 2,037 stars
https://github.com/gocrane/crane
Crane is a Kubernetes-focused FinOps platform for cloud resource analytics, cost visibility, and optimization recommendations.
6. OptScale — 1,999 stars
https://github.com/hystax/optscale
OptScale is an open-source multi-cloud FinOps and cost optimization platform for tracking spend, surfacing savings opportunities, and enforcing governance.
7. Infracost VS Code Extension — 1,845 stars
https://github.com/infracost/vscode-infracost
The Infracost VS Code extension brings Terraform cost estimates directly into the editor so engineers can see cost impact while writing infrastructure code.
8. kubectl-cost — 1,030 stars
https://github.com/kubecost/kubectl-cost
kubectl-cost is a CLI plugin that lets users inspect historical and predicted Kubernetes workload costs from the command line.
9. OpenOps — 1,015 stars
https://github.com/openops-cloud/openops
OpenOps is a no-code FinOps automation platform designed to help teams automate cloud cost operations and workflows with built-in AI assistance.
10. Microsoft FinOps Toolkit — 541–542 stars
https://github.com/microsoft/finops-toolkit
Microsoft FinOps Toolkit is an open-source set of tools, automation, and reference resources for implementing FinOps practices across Azure and Microsoft Cloud.
FinOps Company Spotlight
If you would like your company included in the Spotlight, contact the CloudXray AI Team
Category: Managed Services & Consulting
What They Do: FinOps Consulting & Advisory Services; Owners & maintainers of the single largest FinOps company directory (finops.cloudxray.ai)
Why It Matters: Companies still need guidance on implementing FinOps and understanding the landscape of companies that exist
Operator Playbook
Practical guide for leaders and practitioners
Running Reactive Cost Management as Engineering Work
The General Tech Trends piece made the case. This is the execution.
Reactive cost management works when it is treated as a real engineering backlog — grounded in a north-star KPI, owned by the teams that run the systems, and run on a fixed cadence with throughput metrics. Six rules.
1. Start Narrow — Top 5 to 10 Cost Drivers
Do not try to clean up everything at once.
In most environments, a small number of services and accounts represent a disproportionate share of spend. That is where attention goes first.
Build one list. Tie each item to the north-star metric the organization has agreed on — cost per customer, gross margin by product line, infrastructure spend as a percent of revenue, whatever fits the business. Items that do not move that metric go below the fold. Items that do become the queue.
One list. One metric. One prioritization rule.
2. Every Finding Becomes a Ticket
A recommendation without an owner is a report. Reports do not produce savings.
Every optimization candidate becomes a ticket with:
An owner
An expected outcome
A due date
An estimated impact expressed in the north-star KPI, not just dollars
If the tool cannot route the finding to a person, the tool has not finished its job. If the person cannot own the finding, the org chart has not finished its job. Both are fixable. Neither fixes itself.
3. Batch by Type, Not Dollar Amount
Group all rightsizing candidates into one sprint. Group idle-resource cleanup into another. Group commitment and reservation work into a third.
Context-switching is the tax that kills reactive work. An engineer pulled from a Kubernetes rightsizing pass to go hunt orphaned EBS volumes finishes neither. Big-dollar items are tempting to prioritize individually — resist it. Throughput beats heroics.
4. Ownership Lives With the Team That Runs the System
Not the FinOps team. Not finance. Not a centralized optimization function.
The team that provisions the resource, operates the system, and makes scaling decisions also owns the cost. This is the only ownership model that holds up over quarters. Centralized ownership appears faster but degrades as soon as attention moves elsewhere.
Without this mapping, tasks get reassigned, delayed, or ignored. With it, accountability becomes real — and recurring waste becomes someone's problem instead of everyone's.
5. Integrate Into Existing Cadence
Do not create a parallel process.
Include cost items in sprint planning
Review progress in existing engineering rituals
Protect a fixed time budget — roughly two hours per engineer per week, on the calendar, treated like an on-call shift
Track outcomes alongside other delivery metrics
Cost optimization competes for priority like any other engineering work. Because it is engineering work.
6. Measure Throughput, Not Savings Alone
Savings is the output. Throughput is the process. Track:
Tickets closed per week
Average age of open items
Time-to-close by category
Recurrence rate by workload
Teams that track only savings reward one-off heroics and never build the muscle. Teams that track throughput produce savings as a side effect, every week.
Recurrence is the real test. If the same workload appears on the rightsizing list three quarters in a row, the optimization is not sticking. Something structural is regenerating the waste. That is no longer a reactive FinOps problem — it is an architecture ticket, which belongs upstream.
Which is where next week's issue picks up.