Cost Management | Harness Blog Primary Category

August 10, 2026

Technical

Time to Read

Cloud spend is up 40% year-over-year. Your CFO wants answers.

So your team does the thing everyone does — pulls up the console, starts hunting. Orphaned resources. That RDS instance nobody's touched since Q2. A dev environment three engineers have forgotten exists, quietly billing $800 a month.

You find some waste. You kill it. You send a report. Everyone breathes again.

Until next quarter.

Here's the problem with that reflex — you're asking the wrong question.

"Where are we wasting money?" sounds responsible. But "where are we leaving savings on the table?" is the one that actually changes your trajectory. You're not overspending. You're under-saving. That distinction changes what you measure, what you automate, and ultimately what your cloud bill looks like twelve months from now.

The Reactive Trap: Why Traditional FinOps Misses the Mark

Most FinOps programs run in a reactive mode. A budget alert fires, an exec asks an uncomfortable question, or a surprise bill lands. Teams scramble, find the obvious stuff, ship a report, return to delivery work. Until next time.

This is cost management as damage control. It finds something — these exercises usually do. But they systematically miss everything that didn't make enough noise to trigger a review.

Reserved Instances are a clear example. A reactive team reviews commitment coverage quarterly, maybe monthly if they're disciplined. A proactive team treats it as a continuous process — analyzing utilization patterns, forecasting demand shifts, adjusting before inefficiency compounds. The gap isn't a few percentage points. Over a year, that difference on compute alone can be 15% savings versus 35%.

Cloud Cost Savings Strategy: Building a Proactive Framework

Proactive cloud cost optimization runs on three things: continuous visibility, automated governance, and team-level accountability.

Continuous visibility means treating cost data like application performance data. You wouldn't wait for a service to degrade before checking latency. Every resource should map to a team, service, and environment. When something spikes, you should know within hours, not when the monthly bill arrives.

Dashboards aren't visibility — operational discipline is. Before a developer provisions a new database, they should see the projected monthly cost. When a team's weekly spend jumps 20%, someone should be asking why before the week ends.

Automated governance goes further than guardrails. Budget limits stop runaway costs, but savings automation optimizes what's already running. Idle resource detection, snapshot lifecycle management, rightsizing that executes after approval — these are what separate optimizing once from optimizing continuously.

Here's the mental shift: governance isn't a constraint on engineering. When cost controls are baked in, teams move faster because they're not second-guessing decisions. When finance knows optimization runs systematically, they stop sending nervous emails.

FinOps Best Practices: Accountability Beyond Finance

The biggest obstacle isn't technology. It's org structure.

Most companies centralize cloud cost management in a FinOps team or finance. That team generates reports and recommendations. Engineering teams receive them, nod, and file them under "next sprint." Sometimes that sprint never comes.

That structure almost guarantees under-saving. The people who can change architecture and resource allocation aren't tracking savings opportunities. The people tracking opportunities don't have enough context to know what's worth doing now versus later.

What works: embed cost accountability at the team level. Platform teams own the infrastructure baseline — commitments, shared services, networking architecture. Service teams own their marginal costs — compute, storage, data transfer. Both groups have budgets, both have optimization targets, both report on them in the same cadence they use for reliability and delivery. Not as cost-cutting pressure. As engineering ownership.

This also surfaces trade-offs a centralized team can't see. A 10% cost increase might be pure waste for one team and completely justified for another. Only the team building the service knows which is which.

Maximize Cloud Savings Through Preventive Optimization

Reactive FinOps asks: what can we clean up? Proactive FinOps asks: what are we about to waste?

Developers over-provision for testing and forget to scale down. A reactive team writes a runbook, sends a Slack reminder, adds it to the wiki. A proactive team changes the deployment template — test environments scale down automatically after hours, resources created without tags hit an approval workflow. The waste never happens because the system prevents it.

Storage lifecycle policies archive cold data before it accumulates. Commitment analysis runs daily, catching utilization shifts before they hurt savings rates. Anomaly detection flags unexpected resource creation within the hour.

The cloud cost governance model shifts from periodic audits to continuous validation. A pull request that increases projected spend past a threshold needs cost justification before merge. A service blowing its cost budget gets the same escalation as a service blowing its error budget. Cost feedback runs as tight as your CI/CD pipeline.

Harness CCM: Engineering Proactive Cloud Cost Optimization

Harness Cloud Cost Management is built around this proactive model. Not just tracking what you spent — identifying what you should be saving and providing automation to capture those savings continuously.

Visibility maps to how engineering teams actually work. Every resource ties to a service, team, and environment through automatic tagging and Kubernetes label support, with a unified view across AWS, Azure, and GCP. Costs break down by workload, not just account or region.

Budget tracking adjusts dynamically. Teams set budgets tied to their delivery roadmap and the platform forecasts against actual deployment patterns. Anomaly detection surfaces cost increases before they compound, with enough context to separate signal from noise.

Governance enforces optimization without blocking delivery. Idle resource detection finds underutilized instances, and policy controls define what happens next — notify, require approval, or automate rightsizing. Commitment optimization analyzes Reserved Instance and Savings Plan coverage on an ongoing basis, not just when someone remembers to run a report.

Recommendations quantify trade-offs rather than just flagging problems. Teams see the projected savings from rightsizing a specific instance, the risk of reducing commitment coverage, the benefit of moving a workload to spot instances. Informed decisions instead of guesses.

Cost data integrates into deployment pipelines and operational dashboards alongside reliability and delivery metrics — part of how engineering works, not a separate initiative.

Moving from Reactive to Proactive FinOps

This isn't a project with an end date. It's a change in how teams think about cloud spend.

Teams with strong cost visibility make better architecture decisions during planning, not during post-mortems. They pick storage tiers, compute types, and networking patterns based on actual trade-offs instead of defaults. Finance gets predictability — when optimization runs continuously, cost trajectories stabilize and budget conversations stop being about explaining overruns. Platform teams get time back from repetitive cost hygiene and focus on architecture and reliability.

The under-saving vs overspending paradigm isn't semantic. It's a different operating model. Every dollar left on the table through missed savings is a dollar not funding new capabilities, better reliability, or faster delivery.

Start by measuring what you're not saving. Check your Reserved Instance coverage. Calculate the gap between actual commitment utilization and where it should be. Find resources running overnight that could be scheduled off. Quantify what's available through rightsizing and what it would actually take to capture it.

The number will probably be uncomfortable. It should be. That's what reactive FinOps actually costs — not what you're wasting, but the savings you never went looking for.

Learn more about Cloud Cost Management, check out Harness implementation docs, and see the CCM roadmap.

FinOps Savings Optimization: Stop Overspending, Start Saving

August 4, 2026

Technical

Time to Read

Cloud cost visibility at scale usually works great… until it suddenly doesn’t.

At first, everything feels manageable. You can track spend by service. You know which team owns which resources. Reports are clean, and the numbers make sense.

Then one day, there’s a $47,000 spike spread across three AWS accounts that no one noticed for eleven days. Leadership wants answers. Engineering wants context. And your carefully designed tagging strategy? It turns out half the resources aren’t tagged correctly anymore.

This isn’t about carelessness. It’s about scale.

The systems and processes that work for one account, a few teams, and predictable workloads simply don’t hold up in a fast-growing, distributed, multi-cloud environment. What worked when you had 50 engineers doesn’t scale to 500. Tagging strategies that worked for ten microservices fall apart at a hundred. Manual reviews that felt reasonable in year one become overwhelming operational debt by year three.

Cloud cost management doesn’t fail because teams don’t care. It fails because the model never evolved.

Why Traditional Cloud Cost Visibility Breaks Down

Many organizations still treat cloud spending visibility the way they treated on-prem infrastructure: centralized reports, periodic reviews, and reconciliation after the invoice arrives.

But the cloud doesn’t behave like a static data center.

Infrastructure is provisioned with API calls. Workloads scale up and down automatically. Teams deploy multiple times a day. In that environment, monthly reporting isn’t just slow — it’s disconnected from reality.

1. Cloud Cost Allocation Challenges Multiply Fast

Cost allocation usually starts simple.

You tag an EC2 instance with a team name.
You assign an S3 bucket to a product line.
You map Kubernetes namespaces to cost centers.

Easy enough.

Then things get complicated.

Shared services support multiple teams. A single database might power ten applications. Load balancers route traffic across services owned by different squads. Now your allocation model depends on custom logic, judgment calls, and manual adjustments.

At scale, cloud cost allocation challenges aren’t just about missing tags. They’re about unclear ownership and constantly shifting boundaries.

Without strong FinOps governance and automated enforcement, tagging degrades over time. Trust in the numbers erodes. And once teams stop trusting the data, infrastructure cost transparency disappears.

2. Multi-Cloud Environments Create Fragmented Visibility

Multi-cloud cost governance sounds great in theory. In practice, it’s messy.

AWS, Azure, and GCP all have different pricing models, billing exports, and discount structures. Reserved Instances don’t map cleanly to Committed Use Discounts. Credits and savings plans behave differently. Even basic service naming varies.

Maintaining true cloud spending visibility across providers requires more than dashboards — it requires normalization and context.

Without a unified view, engineers working in AWS don’t see how their choices impact Azure costs. Data teams running BigQuery jobs aren’t aware of the downstream effect on shared networking or storage costs. Everyone optimizes within their silo, but total spend keeps growing.

Enterprise cloud cost optimization can’t happen in fragments. It requires shared visibility across environments.

3. Reactive Reporting Comes Too Late

By the time finance flags a cost spike, the root cause is buried.

The change that triggered it may be three sprints old. The engineer who made it might not even remember. The workload has already scaled, dependencies have grown, and what started as a small inefficiency is now baked into production.

Traditional cloud cost monitoring tools often operate at the billing layer. They tell you what changed — but not why.

Was the spike caused by a misconfigured NAT gateway? An inefficient query? A new feature launch? Increased traffic? The invoice doesn’t know.

Cloud cost visibility at scale requires linking cost signals to engineering context — deployments, configuration changes, usage patterns — before those signals turn into major overruns.

How to Restore Cloud Cost Visibility at Scale

The fix isn’t just better reports. It’s treating cost visibility as an engineering capability.

Cost needs to live inside workflows, not in a finance slide deck.

1. Automate and Deepen Cost Allocation

At scale, allocation can’t be a quarterly cleanup exercise.

You need automated rules that continuously map resources to teams, services, and business units. When something falls outside those rules, it should be flagged immediately — not discovered weeks later during reconciliation.

Strong FinOps governance means allocation is proactive, not reactive.

When teams see near real-time cost impact — through showback or chargeback — behavior changes. Engineers start asking better architectural questions. Optimization becomes part of daily decision-making, not an annual mandate.

2. Use Context-Aware Anomaly Detection

Not every spike is a problem.

A 200% increase during a product launch might be expected. A 200% increase on a quiet Tuesday afternoon probably isn’t.

Effective anomaly detection understands seasonality, traffic patterns, deployment schedules, and baseline behavior. It integrates with observability and CI/CD systems so that when costs change, teams can immediately see what else changed at the same time.

Cloud cost monitoring tools are most valuable when they connect cost signals directly to engineering activity.

3. Make Governance Proactive, Not Punitive

Waiting for an invoice to exceed budget doesn’t protect you.

Instead, set budget thresholds at the team and project level. Trigger approval workflows when provisioning exceeds expected spend. Automatically identify idle or non-compliant resources before they accumulate real cost.

Done right, governance doesn’t slow engineers down. It simply makes cost constraints visible early, when they’re still easy to manage.

How Harness Cloud Cost Management Supports Visibility at Scale

Harness Cloud Cost Management approaches cloud cost visibility at scale as a continuous engineering discipline, not a monthly accounting ritual.

It combines allocation, anomaly detection, and policy enforcement in a way that aligns with how modern teams actually work.

Unified Cost Visibility Across Clouds and Kubernetes

Harness brings AWS, Azure, GCP, and Kubernetes data into a single, consistent view. Engineers can analyze spend by team, namespace, workload, or service without switching dashboards or reconciling inconsistent billing exports.

This unified approach strengthens multi-cloud cost governance while improving infrastructure cost transparency across the organization.

Cost Allocation That Matches Real Ownership

Harness automates allocation using tags, labels, hierarchies, and usage data that reflect how teams structure their work. Shared services and multi-tenant infrastructure are distributed based on actual consumption — not static assumptions.

When allocation logic changes, it updates system-wide. No spreadsheets. No manual reconciliation.

Context-Driven Anomaly Detection

Harness correlates cost spikes with deployments, configuration changes, and infrastructure events. Instead of simply highlighting that spend increased, it surfaces the engineering activity likely responsible.

That’s what makes cloud cost monitoring tools actionable — not just informative.

Governance That Enables Speed

Harness supports budget policies, approval workflows, and automated lifecycle management that prevent overruns without introducing bottlenecks.

Teams keep their autonomy. Finance keeps predictability. Everyone shares visibility.

Learn more about how Harness approaches cost visibility and governance at:
https://www.harness.io/products/cloud-cost-management

Detailed implementation guidance is available at:
https://developer.harness.io/docs/cloud-cost-management

Visibility Creates a Cost-Aware Engineering Culture

Cloud cost visibility at scale isn’t really about dashboards.

It’s about alignment.

When engineers see cost impact in context, when allocation reflects real ownership, and when guardrails are proactive instead of reactive, cost awareness becomes part of the culture.

Without that, organizations fall into a cycle of surprise invoices, reactive firefighting, and growing tension between finance and engineering.

Visibility alone won’t solve cloud cost problems. But without it, enterprise cloud cost optimization is almost impossible.

If your current cloud cost management strategy still revolves around monthly reports and manual reconciliation, the real question isn’t whether you need better dashboards.

It’s whether your engineers have the cost signals they need at the exact moment they make decisions that drive spend.

Why Cloud Cost Visibility at Scale Fails (And How to Fix It)

July 29, 2026

Engineering

Time to Read

A year ago, most of my customer conversations were about cloud cost attribution, commitment coverage, and rightsizing. Classic FinOps stuff. The occasional surprise bill, sure, but nothing that kept anyone up at night. I stopped asking “what was that ‘oh $*#@’ moment when you saw a bill and knew something had gone seriously wrong?” because no one had one of those moments anymore.

Somewhere in the last 12 months, the tables turned and our customers were asking me a serious question: why did my AI bill just do that, and how do I stop it from happening again?

Clearly, something changed. So we ran a study to figure out why.

We surveyed 700 engineering leaders and practitioners across five countries this spring to ask about their organization's FinOps practices. All respondents are at organizations with at least 1,000 employees and real, recurring AI spend, not startups experimenting on a credit card. What we found in the 2026 State of AI in FinOps survey report reads less like a new problem and more like an old one wearing a different jacket.

The pattern I keep seeing

I spent years in FinOps for cloud before AI spend was a line item anyone thought about. But the patterns in the AI billing data – the ownership confusion, the governance gaps, the invoice showing up before anyone understood why – are the same ones we saw in cloud 10-plus years ago. Now, however, the patterns are compressed into a much shorter timeframe and coming at an accelerated pace, if you can believe it.

67% of organizations now spend more than $250,000 a month on AI. 20% have already crossed $1 million a month. At that scale, AI isn't a tool cost anymore, it's a capital decision, which deserves the same governance and attribution discipline it took the industry a decade to build for cloud. We don't have a decade this time.

Ownership is the root, not the symptom

If you ask five people in a typical enterprise who owns AI costs, you'll get five different answers. 52% of respondents told us there's no clear, dedicated AI cost owner in their organization. And the deeper issue isn't that nobody's watching, it's that four different functions are each contributing to the bill. Platform and DevOps teams carry 30% of the accountability, with FinOps 27%, finance 23%, and engineering 19%. No single function comes close to a majority and that is one of the top problems enterprises are facing at the very start.

Meanwhile, engineering and platform teams hold the most influence over spending decisions, more than any function's share of accountability. The disconnect between decision-making and accountability is where a single cost overrun escalates into a full-blown P&L problem.

When the bill doubles overnight

72% of organizations have hit an unexpected AI cost spike or surprise bill in the past year. 1 in 3 have been caught off guard more than once. That alone wouldn't worry me as much if diagnosis were fast. It isn't. 79% report needing a full day or longer to trace a spike back to its source; and roughly a third need a full week. Meanwhile, the bill keeps running.

In the cloud, knowing a spike happened is only the first indication of a problem. Understanding the cause in real-time is where most organizations still fall short, and in today's AI-driven world, the stakes are higher because the spend curve is steeper.

The waste number that should get a CFO's attention

Across the dataset, organizations estimate that 26% of all AI spend is wasted — consistently, across infrastructure, software, models, and services alike. For a company spending $1 million a month, that's $260,000 a month with no measurable return. Just imagine what any enterprise could achieve with that amount of wasted money turned into investments?

Unlike waste in a traditional cloud landscape (are we really, already, calling cloud “traditional” or “legacy”?), this isn't an idle instance somebody forgot to shut down. It's embedded in usage patterns — prompt design, model selection, retry logic — none of which currently carries a cost signal. 56% of engineering leaders told us their teams don't have cost in mind when building AI features, and only 45% of engineers, on average, understand what their builds actually cost.

That's not a motivation problem. In our FinOps in Focus Report 2025, 62% of developers said they wanted more control over cloud costs, and there's no reason to think AI is any different. The problem is a lack of visibility, not a misalignment of intent. The data simply isn't in front of people when the decisions get made.

Policy on paper, not in practice

The instincts are right; the operational muscle isn't there yet. 73% of organizations say they have an AI cost policy. Only 47% fully enforce it. That's a 26-point gap between what's written down and what actually happens day to day. Policies that don't show up in the tools engineers actually use tend to get ignored, because the incentive to move fast usually wins.

Only 21% describe their AI cost management as fully mature company-wide, and only 26% have a robust way of measuring the business value of their AI spend at all. Four in five organizations simply aren't there yet.

‍Building an AI ROI Culture

What I keep coming back to is that the hardest part of this isn't technical. It's cultural and organizational. The tooling is catching up. The harder work is getting engineering teams to build with cost in mind from the start, not as a constraint, but as a design principle.

The organizations in our data that did reach maturity didn't try to fix everything at once. They followed a fairly consistent sequence:

name an owner before buying a tool,
build a unified cost view before optimizing,
embed cost data into engineering workflows before writing policy,
and establish unit economics tied to real business outcomes before chasing ROI.

Use this report to find out where your organization stacks up against others in the industry and how mature enterprises are getting ahead of AI cost blindspots..

Download and learn more about the 2026 State of AI in FinOps.

Cloud Asked What It Cost, AI Is Asking What It's Worth

July 24, 2026

Technical

Time to Read

Why does developer productivity feel like it's declining even as your team grows? You hire more engineers, yet features ship slower. Sprint velocity looks healthy on paper, but deployment frequency tells a different story. The standups get longer, the Slack channels multiply, and somehow everyone is busy but nothing feels finished.

This disconnect isn't about effort. It's about visibility. Most engineering leaders lack the instrumentation to distinguish between legitimate delivery constraints and workflow friction that scales linearly with headcount. They track story points and commit counts while the actual bottlenecks hide in handoff delays, review queues, and context switching that never shows up in a burndown chart.

The following eight questions cut through vanity metrics to expose what actually moves the needle on software engineering efficiency. They're not comfortable questions. Some will reveal problems you'd rather not acknowledge. But answering them honestly is the difference between scaling a team and scaling chaos.

What Does Developer Productivity Actually Mean for Your Team?

Before you can improve engineering productivity metrics, you need to define what productivity means in your context. A platform team optimizing infrastructure has different success signals than a feature squad shipping user-facing changes. Conflating these creates metrics theater where everyone reports green while delivery quality erodes.

Developer productivity breaks into three layers that often conflict. Individual throughput measures coding speed and task completion. Team velocity captures collaborative output including reviews, deployments, and knowledge transfer. Business impact tracks whether engineering work actually moves strategic objectives forward.

The mistake is optimizing one layer at the expense of others. A developer cranking out pull requests might be fragmenting the codebase. A team hitting sprint commitments might be ignoring technical debt that will crater velocity in six months. High deployment frequency means nothing if you're deploying the wrong features.

Define productivity through the lens of sustainable delivery. Can your team maintain current output six months from now without burning out? Are you building technical leverage or accumulating complexity tax? The answers shape which metrics matter.

Are You Measuring Activity or Outcomes?

Lines of code, commit frequency, and hours logged are activity metrics. They tell you what engineers are doing, not whether it matters. Activity metrics create perverse incentives where developers optimize for measurement rather than impact.

Developer workflow optimization requires outcome-based measurement. How long does it take to ship a customer-facing change from commit to production? What percentage of deployments require rollback? How many production incidents trace back to code merged in the last sprint? These questions connect engineering work to business consequences.

DORA metrics provide a framework grounded in delivery outcomes. Deployment frequency, lead time for changes, change failure rate, and time to restore service capture the feedback loops that separate high-performing teams from the rest. They're leading indicators of engineering health because they measure your ability to deliver value reliably.

The trap is collecting DORA metrics without understanding the workflows they represent. A team with high deployment frequency but terrible lead times might be shipping small cosmetic changes while complex features rot in long-lived branches. Context matters more than the numbers.

Where Are Your Team Productivity Measurement Blind Spots?

Most engineering organizations track what's easy to measure and ignore what actually constrains throughput. Pull request metrics are abundant. Build system performance data is scattered across Jenkins logs. Incident response times live in PagerDuty. Requirements churn never gets quantified at all.

Team productivity measurement fails when it doesn't capture the space between commits. How long do pull requests sit in review queues? What percentage of engineering time goes to unplanned work driven by production issues? How often do spec changes force rework after development starts? These invisible delays compound into delivery drag that conventional metrics miss entirely.

Workflow visibility requires stitching data across systems. Source control shows when code was written, not when it was ready for review. CI pipelines show build duration, not queue time. Issue trackers show ticket status, not the three days spent waiting for product clarification. Without integration, you're optimising local maxima while system-level bottlenecks persist.

The hardest blind spot is cultural. Are engineers afraid to flag blockers because leadership interprets them as excuses? Does your retrospective process surface genuine impediments or just generate action items that never get addressed? Measurement infrastructure means nothing if teams don't trust the data will be used constructively.

What Percentage of Your Engineering Capacity Goes to Unplanned Work?

Unplanned work is the silent killer of developer experience. Every production incident, urgent bug fix, and surprise escalation from sales interrupts flow state and fractures focus. A team that looks 80 percent utilized on sprint planning is actually 50 percent effective after accounting for firefighting.

Engineering velocity collapses under unplanned work load because context switching isn't free. Dropping a feature branch to fix a production issue costs more than the fix itself. You lose the mental model of what you were building, the architectural decisions that informed your approach, and the momentum toward completion. Regaining that context takes time measured in hours, not minutes.

Track interrupt ratio as a first-class metric. What percentage of story points delivered each sprint were unplanned? How many engineer-days per month go to incidents versus roadmap work? How often do critical path features miss deadlines because the team was pulled into emergency mode? These numbers reveal whether you're running an engineering organization or an operational fire brigade.

Reducing unplanned work requires investment in reliability, observability, and proactive incident prevention. It also requires saying no. Not every escalation is truly urgent. Not every bug justifies interrupting a sprint. Protecting engineering focus is a leadership decision, not a technical one.

How Long Does It Take to Get Feedback on Code Quality?

Developer productivity tools only matter if they shorten feedback loops. A test suite that takes four hours to run might catch bugs, but it trains developers to batch changes and avoid frequent commits. A pull request that sits for three days accumulates merge conflicts and bit rot. Delayed feedback is expensive feedback.

Fast feedback enables iterative improvement. Developers adjust their approach based on test results, review comments, and production behaviour. When that feedback arrives within minutes instead of days, quality improvements compound. Code reviews become conversations instead of asynchronous bottlenecks. Bugs get caught before they escape the developer's working memory.

The goal isn't just speed. It's actionability. A CI pipeline that fails instantly but produces cryptic error messages creates frustration, not productivity. A monitoring system that alerts on every minor blip trains teams to ignore signals. Feedback quality matters as much as feedback speed.

Measure feedback latency across the entire delivery pipeline. How long from commit to CI results? From pull request open to first review? From merge to production deploy? From deploy to user impact visibility? Each delay point represents an opportunity for improvement or a constraint that's being accepted as the cost of doing business.

Are Your Engineering Productivity Metrics Driving the Wrong Behavior?

Metrics shape behavior. Measure pull request volume and developers will split changes into trivially small commits. Measure story points completed and teams will game estimation. Measure individual output and collaboration suffers. The question isn't whether metrics influence behaviour but whether they're encouraging the behaviour you actually want.

Engineering productivity metrics should reinforce team health and sustainable delivery. DORA metrics work because they measure system-level outcomes that require collaboration to improve. You can't game deployment frequency without also improving your build and test infrastructure. You can't fake low change failure rates without investing in quality practices.

The danger is treating metrics as performance scorecards instead of diagnostic tools. When management uses productivity data to rank individuals or teams, trust evaporates. Engineers optimize for metrics instead of outcomes. The dashboards stay green while delivery quality degrades. Productivity measurement becomes counterproductive.

Use metrics to surface questions, not assign blame. Why did lead time spike last month? What's causing the increase in change failure rate? Where are the review bottlenecks that slow down this particular team? The goal is to identify improvable constraints, not to shame teams into working faster.

Do You Understand the Relationship Between Developer Experience and Business Outcomes?

Developer experience directly impacts business results through retention, velocity, and quality. Engineers who spend half their day fighting broken tooling deliver less value. Teams that can't deploy without manual approvals ship slower. Organisations that ignore developer frustration lose their best people to competitors with better engineering cultures.

Poor developer experience compounds. A slow build system adds minutes to every code change. A flaky test suite makes deployments risky. An overloaded review process creates merge conflicts. Each friction point individually seems minor. Together, they create an environment where shipping software feels like pushing a boulder uphill.

The business case for improving software engineering efficiency is straightforward. Faster feedback loops mean faster iteration. Lower change failure rates mean less time spent on incident response. Better tooling means engineers spend more time building and less time fighting infrastructure. These improvements show up in reduced time to market and higher team output.

Track developer experience through both quantitative and qualitative signals. Survey results capture sentiment. Turnover rates reveal whether frustration is driving attrition. Deployment frequency and lead time show whether workflow improvements translate to delivery acceleration. The combination paints a complete picture of engineering health.

How Does Harness SEI Answer These Questions?

Most engineering organizations already collect a lot of data. The problem isn’t a lack of metrics — it’s that the signals are scattered across different systems.

Code activity lives in source control. Build performance sits inside CI pipelines. Work tracking happens in ticketing systems. Incident response lives somewhere else entirely. Each tool tells part of the story, but none of them show how work actually flows through the delivery system.

Harness Software Engineering Insights (SEI) connects those signals so engineering leaders can understand what’s really happening across the development lifecycle.

Connecting the delivery data

SEI integrates with the tools engineering teams already use — including source control platforms and issue tracking systems — and consolidates that data into a unified view of engineering delivery.

Instead of looking at isolated reports from individual systems, teams can analyze how work moves from planning to development, through code review, and into deployment. This makes it easier to see where delays accumulate and how workflow patterns change over time.

Measuring delivery performance

SEI provides built-in engineering delivery metrics, including industry-standard indicators such as DORA metrics and pull request lifecycle analytics.

These metrics help answer questions like:

How long does it take for a change to move from development to deployment?
Where do pull requests spend the most time waiting?
Are deployment and delivery patterns improving or slowing down?

Because these metrics track system-level outcomes rather than individual activity, they provide a more reliable view of engineering performance.

Visualizing workflow trends

SEI surfaces these signals through configurable Insights dashboards, where engineering leaders can explore delivery trends and drill into the underlying data.

These dashboards make it easier to identify patterns that aren’t obvious from individual tools — for example, whether review queues are slowing down merges, whether certain teams experience longer lead times, or whether workflow improvements are actually reducing delivery friction.

Instead of reacting to anecdotal feedback, teams can use these insights to investigate where bottlenecks might exist.

Adapting metrics to your organization

Developer productivity doesn’t look the same for every team. Platform teams, infrastructure teams, and product engineering groups often measure success differently.

SEI allows organizations to define custom metrics and measurement frameworks based on how their teams actually work. This flexibility helps engineering leaders evaluate delivery performance, workflow efficiency, or engineering investment without forcing every team into the same definition of productivity.

Understanding how engineering effort is spent

Beyond delivery speed, engineering leaders also need visibility into where engineering time goes.

SEI supports configurable profiles that help organizations analyze both delivery performance and engineering investment. Teams can examine how work is distributed across areas like feature development, maintenance, bugs, or technical debt — helping leaders understand whether engineering effort aligns with business priorities.

Turning visibility into better decisions

The goal of developer productivity measurement isn’t to monitor developers more closely. It’s to understand how the delivery system behaves.

By connecting engineering data, surfacing delivery metrics, and visualizing workflow trends, Harness SEI helps organizations move beyond guesswork and answer the kinds of questions that actually drive engineering improvement.

When teams can see where work slows down, where effort is being spent, and how delivery patterns evolve over time, they’re better equipped to remove friction and support sustainable developer productivity.

The Questions Lead to Better Answers

Developer productivity improvement starts with honest assessment of current state. The eight questions above force engineering leaders to confront uncomfortable truths about workflow inefficiencies, measurement gaps, and cultural barriers that prevent teams from performing at their potential.

The answers vary by organization, but the pattern is consistent. Teams improve when they have visibility into their delivery process, feedback loops that enable rapid iteration, and leadership that treats productivity metrics as diagnostic tools rather than performance scorecards. The technology enables visibility. The culture determines whether that visibility drives meaningful change.

Start by picking one question and answering it with data. Instrument the workflow. Track the metric. Review the trend. Use what you learn to inform the next improvement. Sustainable productivity gains compound through small, validated changes rather than large, disruptive transformations.

The goal isn't perfect measurement. It's sufficient visibility to make better decisions. You don't need to know everything about your engineering process. You need to know enough to identify the next constraint worth addressing. That's how high-performing teams stay high-performing even as they scale.

You can explore Harness SEI and review implementation details or explore the roadmap to learn how the platform continues evolving to address emerging engineering productivity challenges.

Boost Developer Productivity: 8 Key Questions

July 24, 2026

Technical

Time to Read

Ever wonder why your FinOps savings optimization efforts feel like playing whack-a-mole with service quotas while your CFO still asks why cloud spend keeps climbing? You're not alone. Most teams approach cost management as a quarterly fire drill—identify overruns, kill underutilized resources, negotiate better rates, then repeat the cycle three months later.

In recent years a more accurate framing has emerged—and it’s reshaping how leading enterprises approach cloud economics:

You’re not overspending. You’re under-saving.

That shift isn’t just a catchy line. It’s the difference between reacting to cloud bills and systematically capturing savings before waste ever becomes spend. And once you see cloud cost through this lens, it becomes clear why so many cloud programs plateau: they’re trying to optimize after the fact.

The problem isn't that teams are spending recklessly. It's that they're systematically missing the largest pool of potential savings: the costs they never should have incurred in the first place.

The Real FinOps Paradigm Shift: From Cost Control to Value Creation

The traditional cloud cost savings strategy treats spend as a problem to solve after deployment. Teams spin up infrastructure, run workloads for weeks or months, then scramble when finance flags the variance. By then, architectural decisions are locked in. Instance families are chosen. Data transfer patterns are established.

The opportunity to prevent those costs expired the moment the first commit hit production.

The real FinOps paradigm shift isn’t better dashboards or faster anomaly alerts. It’s moving from cost control (looking backward) to value creation (looking forward). When we focus on overspending, we’re asking: What went wrong? When we focus on under-saving vs overspending, we’re asking: What could have been optimized?

Because here’s the uncomfortable truth:
Every unsaved dollar is a lost opportunity — and those opportunities can compound quickly.

Why Traditional FinOps Cost Optimization Frameworks Miss the Target

Standard FinOps cost optimization frameworks focus on three levers: rightsizing, commitment-based discounts, and resource lifecycle management. These tactics work. They're also insufficient at scale because they treat the symptom, not the cause.

Rightsizing saves 15-20% on compute that shouldn’t be running at that scale in the first place.
Reserved instances lock in discounts on workloads that might disappear next quarter.
Automated shutdowns prevent idle waste but don’t question why the resource exists.

And most importantly: traditional FinOps often assumes you already have attribution solved.

But most organizations don’t.

At the last FinOpsX conference, one stat stood out because it explains why cost programs stall:

Only 37% of enterprise companies can achieve 80% or greater tagging accuracy for showback purposes.

Meaning: most enterprises are “flying blind” on a meaningful chunk of their spend. Not because they lack dashboards—but because they can’t reliably connect costs to owners, services, or outcomes.

The Foundation: You Can’t Optimize What You Can’t Attribute

The path to meaningful cloud optimization starts with a simple truth:

You can’t optimize what you can’t attribute.

Yet most organizations struggle with basic cost attribution, leaving 40–60% of their spend unallocated across:

Shared resources with no clear ownership split
Legacy systems with unknown owners
Cross-functional services used by multiple teams
Infrastructure components that span business units

This isn’t just a reporting problem. It’s an optimization blocker.

Because if teams can’t see their real costs, they can’t make informed decisions about architecture, service ownership, or operational tradeoffs. They default to safe-but-expensive patterns: overprovisioning, indefinite retention, and “just in case” redundancy.

That’s not overspending. That’s under-saving.

Proactive Cloud Cost Management Starts Before Deployment (Not After the Invoice)

Shifting to proactive cloud cost management requires embedding cost awareness into engineering workflows, not appending it afterward.

That means surfacing estimated spend during:

Code review
CI pipelines
Infrastructure as Code changes
deployment approvals

This isn’t about blocking deployments or adding bureaucratic gates. It’s about making cost a first-class design constraint, like latency or error rates.

The most innovative FinOps organizations are moving toward what is called a “zero drift” model: embedding cost optimization directly into the development and deployment pipeline so inefficiency never ships.

Instead of discovering optimization opportunities after resources are deployed, zero drift ensures that:

Infrastructure is provisioned with optimal configurations from day one
Tagging policies are enforced at deployment time
Resource selections align with existing commitment purchases
Guardrails prevent expensive mistakes before they happen

This is where the best cloud savings opportunities actually live: not in post-hoc cleanup, but in pre-production prevention.

Beyond Dashboards: Always-On Systems That Never Sleep

Real savings don’t come from dashboards. They come from systems that never sleep.

Traditional FinOps relies on periodic reviews and manual interventions. But modern cloud environments are too dynamic for that. Workloads shift daily. Teams deploy constantly. Kubernetes autoscaling changes cost behavior in real time. No human review process can keep up.

To maximize cloud cost efficiency, optimization has to be:

Continuous
Automated
Anforced through governance
Connected to engineering workflows

This is the difference between a FinOps program that “reports” and a FinOps program that actually saves.

Cloud Cost Governance Best Practices That Scale with Teams

Effective cloud cost governance best practices balance autonomy with accountability. Overly restrictive policies slow teams down and create shadow IT. Overly permissive policies lead to unchecked spend and architectural drift.

The solution is policy-driven guardrails that prevent obvious waste without requiring centralized approval for every resource change.

Examples include:

Enforcing tagging standards for cost allocation
Setting spend thresholds that trigger reviews
Flagging resources that violate efficiency baselines
Requiring approved instance families in production
Blocking deployments when mandatory tags are missing

Tagging discipline remains the foundation. Without consistent tagging, showback and chargeback models collapse, and optimization becomes guesswork.

Engineering Economics: Making Optimization Everyone’s Job

One of the biggest blockers in traditional FinOps is the disconnect between:

The teams who identify optimization opportunities (finance)
And the teams who must implement them (engineering)

This is why cost optimization often feels like cost policing.

To fix it, organizations need to make cloud cost management an engineering discipline—supported by unit economics and workflow integration.

High-performing teams connect technical decisions to business outcomes using metrics like:

Cost per transaction
Cost per user
Cost per deployment
Cost per environment
Cost per SKU

When engineers can see how their architectural choices translate to dollars, optimization becomes a natural part of delivery—not an external mandate.

How Harness Cloud Cost Management Enables Proactive FinOps Savings Optimization

Harness Cloud & AI Cost Management provides the visibility and control infrastructure needed to shift from reactive cost cuts to proactive savings.

Unlike platforms built primarily for post-invoice reporting, Harness integrates cost awareness directly into deployment workflows—surfacing spend data at the point where engineering decisions are made.

Harness CCM strengthens FinOps savings optimization through:

1) Intelligent rule-based retro-tagging
Most enterprises don’t reach consistent tagging accuracy manually. Harness CCM solves this with automated retro-tagging that classifies untagged resources using:

resource groups
naming conventions
subscription metadata
deployment pipeline data

This can help organizations achieve tagging accuracy up to 98%, unlocking reliable showback, chargeback, and accountability.

2) Shared cost allocation for real attribution
Harness CCM supports sophisticated shared cost allocation so organizations can distribute costs (like AWS support contracts) proportionally based on actual usage—not arbitrary splits.

3) Always-on optimization systems
Harness CCM replaces periodic reviews with continuous automation, including:

AI-powered right-sizing based on real workload requirements
commitment orchestration that executes optimization actions daily
anomaly prediction that flags spikes before budgets are impacted
policy-driven guardrails that prevent drift in new deployments

4) Shift-left “zero drift” enforcement
Harness integrates with CI/CD and IaC workflows so teams can enforce cost policies at deployment time, including mandatory tagging and approved resource patterns.

The Path Forward: From Cost Cutting to Systematic Under-Saving Recovery

The transition from reactive cost cutting to proactive savings optimization requires three shifts:

Fix attribution first (tagging + shared cost allocation)
Move optimization from periodic to always-on
Shift left to prevent waste from being deployed

These aren’t cultural aspirations. They’re engineering problems with technical solutions.

The organizations winning at cloud cost management aren’t the ones cutting budgets or negotiating better discounts. They’re the ones that stopped accepting architectural inefficiency as inevitable and started designing cost efficiency into every deployment.

The opportunity isn’t in finding waste after it accumulates.

It’s in building systems that prevent waste from ever becoming spend in the first place.

What To Go Deeper?

Watch our webinar, You’re Not Overspending, You’re Under-saving to learn more.

For teams looking to implement a cloud cost savings strategy that goes beyond reactive cuts, Harness CCM provides the operational foundation for proactive cost management. Learn more at or explore technical implementation details.

You're Not Overspending, You're Under-Saving: A New FinOps Paradigm

July 24, 2026

Technical

Time to Read

Your cloud cost optimization strategy just flagged a $47,000 anomaly in last month's Kubernetes spend. Finance wants answers. Engineering claims everything is running normally. Platform teams are scrambling through logs. Three hours later, you discover the spike came from a staging environment that someone forgot to tear down after a load test two weeks ago. The tooling caught the symptom. Your approach missed the disease.

This scenario repeats across organizations daily. Teams invest in sophisticated monitoring, deploy dashboards, set up alerts, then watch their cloud bills climb anyway. The problem is not the tooling. It is the assumption that visibility alone drives accountability.

Why Traditional Cloud Cost Optimization Approaches Fail

Most cloud cost optimization challenges stem from treating cost management as a periodic cleanup exercise rather than an operational discipline. Organizations implement dashboards, generate monthly reports, and schedule quarterly reviews. Then they wonder why engineers ignore the recommendations and spend continues growing.

The gap lies in the feedback loop. When cost data arrives weeks after the spending decision, engineers cannot connect their architectural choices to financial outcomes. A developer deploys a new microservice with default resource requests. Three weeks later, someone in finance notices the overprovisioning. By then, the service is in production, and rightsizing it requires another deployment cycle that nobody prioritizes.

This delayed accountability creates a culture where cost optimization becomes someone else's problem. Engineering builds features. Finance tracks spending. Platform teams inherit the reconciliation work. Nobody owns the relationship between technical decisions and their financial consequences.

The Reactive Cycle That Perpetuates Cloud Cost Optimization Challenges

Reactive cloud cost management approaches follow a predictable pattern. Teams deploy infrastructure, operate services, receive bills, analyze spending, identify waste, create tickets, prioritize work, and finally implement fixes. By the time optimization happens, new inefficiencies have already accumulated.

Consider how teams handle idle resources. Someone notices an underutilized EC2 instance during the monthly cost review. They create a ticket to investigate. Engineering confirms it is no longer needed. The ticket goes into the backlog. Two sprints later, someone finally terminates the instance. Meanwhile, that resource consumed another $600 in unnecessary spend.

This reactive model fails at scale because cloud environments change faster than monthly review cycles can track. Teams launch experiments, provision temporary infrastructure for testing, scale services to handle traffic spikes, then forget to scale back down. Each decision makes sense in isolation. Collectively, they create persistent waste that compounds month over month.

The FinOps strategy required to break this cycle involves embedding cost accountability into the workflows where spending decisions actually happen, not bolting it on afterward through reporting.

Building a Cloud Cost Governance Framework That Scales

Effective cloud spend optimization requires governance mechanisms that operate in real time, not historical analysis. Teams need to understand the cost implications of their architectural choices before those choices reach production, not weeks later when bills arrive.

This means establishing cost guardrails at the infrastructure provisioning layer. When an engineer requests resources, they should see projected spend alongside technical specifications. When a team deploys a new service, cost allocation should happen automatically based on tagging policies. When usage patterns change, teams should receive immediate feedback about the financial impact.

The cloud cost governance framework must also address ownership boundaries. Which team owns the cost of shared infrastructure? How do you allocate spending for platform services consumed by multiple applications? Who decides when optimization work takes priority over feature development?

Organizations that answer these questions clearly create sustainable cloud cost optimization best practices. Those that leave ownership ambiguous end up with fragmented accountability where nobody feels responsible for the overall spend.

Implementing a Sustainable Cloud Cost Management Approach

A functioning cloud cost management approach requires three operational components: real-time visibility into spending patterns, automated allocation to responsible teams, and integration with existing development workflows.

Real-time visibility means engineers see cost data during development, not during retrospectives. When someone modifies resource requests in a Kubernetes manifest, they should understand the monthly cost difference immediately. When a team considers using a managed service versus self-hosting, cost implications should inform the architectural discussion.

Automated allocation eliminates the manual reconciliation work that consumes platform team capacity. Tags applied during resource provisioning should automatically map spending to teams, services, and environments. Cost data should flow into the same systems teams already use for capacity planning and incident management.

Workflow integration ensures cost optimization does not become isolated work. Rightsizing recommendations should appear in pull requests. Anomaly alerts should route to the same channels as performance alerts. Budget tracking should connect to the same approval workflows used for infrastructure changes.

This integration transforms cost optimization from something teams do occasionally to something embedded in how they operate continuously.

How Harness Cloud Cost Management Enables Governance at Scale

Harness Cloud & AI Cost Management addresses these operational requirements by treating cost visibility as infrastructure, not reporting. The platform provides real-time cost tracking across AWS, Azure, and GCP, with automatic allocation based on Kubernetes labels, cloud tags, and organizational structure.

Teams get cost breakdowns by service, environment, and business unit without manual tagging reconciliation. Budget tracking operates continuously with anomaly detection that routes alerts to the teams responsible for the spending. Optimization recommendations appear in context where engineers already work, not in separate dashboards they need to remember to check.

The governance capabilities extend beyond visibility. Harness CCM enables policy-based cost controls that prevent wasteful configurations before they reach production. Teams can set budget guardrails, enforce tagging policies, and establish approval workflows for high-cost resources.

This approach shifts cost accountability left in the development process. Engineers see the financial impact of their decisions during design and implementation, when changes are cheap to make. Platform teams get automated allocation that eliminates manual reconciliation. Finance gets accurate forecasting based on actual resource usage patterns.

Because Harness CCM integrates with broader platform and delivery workflows, cost optimization becomes part of the deployment process rather than separate cleanup work. Rightsizing recommendations flow into the same pipelines teams use for continuous delivery. Cost trends inform capacity planning alongside performance metrics.

For organizations implementing FinOps practices at scale, this integration matters. Cost management cannot operate in isolation from the technical workflows that generate spending. Tools that treat cost as an afterthought create friction that engineering teams route around. Platforms that embed cost visibility into existing processes enable the shared ownership required for sustainable optimization.

The platform documentation provides implementation patterns for teams moving from reactive cost management to proactive governance. The product roadmap shows ongoing investment in capabilities that strengthen cost accountability across the software delivery lifecycle.

Establishing Sustainable Cloud Cost Optimization Best Practices

Sustainable optimization requires treating cost as an operational concern, not a financial reporting problem. Teams that build cost awareness into their development practices avoid the accumulation of waste that reactive approaches never fully eliminate.

This cultural shift begins with transparency. When every team sees their spending in real time, cost becomes a shared responsibility. When budgets connect to technical decisions, engineers understand the financial consequences of architectural choices. When optimization recommendations appear during code review, addressing inefficiency becomes part of normal development work.

Organizations implementing this approach report sustained reductions in cloud spend without sacrificing delivery velocity. Engineering teams make better trade-offs because they understand cost implications alongside technical considerations. Platform teams spend less time on manual reconciliation and more time on automation that prevents waste. Finance gets predictable spending patterns because budgets connect to the workflows that generate costs.

The key is embedding cost accountability where spending decisions happen, then providing the guardrails and visibility required to act on that accountability continuously.

---

Your staging environment is still running. The difference is that now you know about it immediately, the responsible team gets an automatic alert, and your governance policies prevent similar waste from accumulating next time. That is not better reporting. That is a better approach.

Cloud Cost Optimization Strategy: Fix Your Approach

July 23, 2026

Technical

Time to Read

Why does your platform team get blamed when engineer cloud cost awareness doesn't exist, even though they built perfectly functional infrastructure? Because someone deployed a compute-intensive job to production without checking if it would consume $40,000 of spot instances overnight. The engineer who shipped it had no visibility into cloud costs, no incentive to check, and no workflow that surfaced the impact until finance sent an escalation email three weeks later.

This isn't an engineering failure. It's a systems design failure. When cost visibility lives in a separate dashboard that developers never open, cost accountability for developers becomes impossible. Teams optimize for shipping velocity, reliability, and feature completeness because those metrics are visible, measured, and rewarded. Cloud spend remains invisible until it becomes a crisis.

Why Engineering Team Cost Visibility Fails at Scale

The root problem isn't awareness. Engineers care about operational impact when it affects their work directly. They care about latency because it shows up in monitoring. They care about error rates because on-call pages them at 3 AM. Cloud costs don't trigger any of these feedback loops. The bill arrives weeks after deployment, attributed to abstract cost centers that don't map to services or teams.

Most organizations hand engineers access to a FinOps dashboard and expect behavioral change. This approach fails because it treats cost awareness as an individual responsibility rather than a systemic property. Developers should not need to context-switch into a separate cost analysis tool to understand the impact of their architectural decisions. By the time they check, the damage is already done.

Traditional cost reporting tools create a 20 to 30-day delay between action and feedback. Engineers deploy infrastructure changes, move on to the next sprint, and only discover the cost impact during the monthly retrospective. At that point, the deployment is in production, dependencies have been built on top of it, and rolling back feels riskier than absorbing the cost. This delay decouples decision-making from consequences, which is the opposite of how platform engineering should work.

Cloud Cost Governance for Engineers Needs Guardrails, Not Guidelines

Most organizations approach developer cloud cost responsibility through documentation: cost allocation tagging standards, rightsizing recommendations, and quarterly cost reviews. These are necessary but insufficient. Documentation creates awareness but doesn't enforce accountability. Engineers will follow guidelines when they have time, which means they follow them inconsistently.

Effective engineering cloud spend optimization requires guardrails embedded into the deployment workflow. If a service exceeds its cost budget, the pipeline should surface that information before merge, not after deployment. If an environment spins up resources that violate governance policies, the provision request should be blocked, not logged for post-incident analysis.

This doesn't mean slowing down deployments with manual approval gates. It means making cost governance automated, predictive, and contextual. Engineers should know the cost implications of scaling decisions at the same moment they're making them. If a pull request changes autoscaling thresholds, the cost impact should appear in the code review, not in next month's bill.

The Incentive Misalignment Problem

Engineering team cost visibility fails when performance reviews, promotion criteria, and operational metrics ignore cost efficiency. Platform teams are measured on uptime, deployment frequency, and feature delivery. Nobody gets promoted for saving $200,000 in unnecessary compute spend. This creates a rational optimization strategy: prioritize what gets measured, ignore what doesn't.

Finance teams notice this misalignment when cloud budgets grow 40 percent year-over-year while engineering headcount stays flat. They respond by implementing cost controls, which engineers experience as friction. The typical result: shadow IT workarounds, requests for budget exceptions, and a growing adversarial relationship between engineering and finance.

The fix isn't tighter controls. It's making cost a first-class operational metric alongside latency, error rates, and throughput. If cost per transaction appears in the same dashboards engineers check during incidents, it becomes part of the operational model. If cost anomaly alerts route to the same channels as performance alerts, teams respond with the same urgency.

Building Cost-Aware Engineering Practices That Scale

FinOps culture adoption starts by treating cost visibility as infrastructure, not training. Engineers shouldn't need to learn a new cost analysis methodology to understand whether their deployment will double the monthly bill. Cost data should flow into the tools they already use: observability platforms, CI/CD pipelines, and service catalogs.

The shift from cost-oblivious to cost-aware engineering happens through three mechanisms: real-time feedback, team-level accountability, and policy automation. Real-time feedback means engineers see projected cost changes during development, not weeks after deployment. Team-level accountability means costs are allocated to services and owners, not abstract cost centers. Policy automation means governance rules are enforced by the platform, not spreadsheets.

Start with cost allocation. Every cloud resource should be tagged with the service, team, and environment that owns it. This enables accurate attribution, which is the foundation for accountability. Without it, platform teams end up playing cost detective, trying to figure out which $15,000 database instance belongs to which product team.

Next, integrate cost data into existing workflows. If engineers deploy through Terraform, cost estimates should appear in plan output. If they provision resources through an internal developer platform, cost projections should display before submission. If they query logs in Datadog or Splunk, cost per query should be surfaced alongside latency metrics.

Finally, implement budget guardrails that escalate based on severity. Minor overruns trigger notifications. Moderate overruns require acknowledgment. Critical overruns block deployments until reviewed. This creates proportional friction: small costs flow freely, large costs require deliberate decisions.

What Cost Accountability for Developers Actually Looks Like

Real cost accountability doesn't mean every developer needs to become a cloud economist. It means platform teams provide the infrastructure for cost-aware decision-making. Engineers should be able to answer: "Will this change increase our monthly cloud spend?" without leaving their IDE.

This requires cost visibility at multiple layers. At the service level, teams need dashboards showing spend trends, budget burn rate, and cost per transaction. At the environment level, they need to see whether dev and staging environments are consuming production-level resources. At the resource level, they need rightsizing recommendations that map to actual workload patterns.

The goal is to make the economically optimal choice also the path of least resistance. If oversized instances cost more and require justification, engineers will rightsize by default. If unutilized resources trigger automated cleanup workflows, teams won't accumulate zombie infrastructure. If cost-efficient architectures are templated and documented, they become the starting point for new services.

How Harness CCM Embeds Cost Awareness Into Platform Workflows

Harness Cloud & AI Cost Management treats cost visibility as a core platform capability, not a separate FinOps tool. It integrates cost data directly into delivery workflows, making engineering cloud spend optimization a natural part of the development process rather than an afterthought.

The platform provides real-time cost allocation across AWS, Azure, and GCP, breaking down spend by service, team, environment, or business unit. This eliminates the attribution problem that makes traditional cost reporting useless for engineering teams. Instead of seeing a $200,000 monthly bill with no context, teams see exactly which services, deployments, and resource types drive costs.

Budget tracking and anomaly detection run continuously, surfacing cost spikes before they compound into major overruns. When a deployment unexpectedly doubles compute costs, the alert routes to the engineering team that owns the service, not a centralized FinOps group. This creates the tight feedback loop that traditional cloud billing tools cannot provide.

Policy-based cost controls enforce governance at provision time, not during retrospectives. If a team attempts to deploy resources that violate cost policies, the request surfaces recommendations before execution. This prevents the "deploy first, optimize later" pattern that leads to permanent inefficiency.

Harness Cloud & AI Cost Management integrates with broader platform and delivery workflows, meaning cost data flows into CI/CD pipelines, observability dashboards, and service catalogs. Engineers don't need to context-switch into a separate cost tool to understand the financial impact of their decisions. Cost becomes part of the operational model, measured and optimized alongside performance and reliability.

The platform also provides optimization recommendations grounded in actual workload patterns. Rather than generic rightsizing suggestions, it analyzes utilization trends and suggests specific actions: terminate unused resources, convert on-demand instances to reserved capacity, or adjust autoscaling thresholds. These recommendations integrate into existing workflows, reducing the activation energy required to act on them.

For organizations implementing FinOps culture adoption, Harness Cloud & AI Cost Management supports the transition from reactive cost management to proactive governance. It provides the infrastructure for developer cloud cost responsibility without requiring every engineer to become a cost expert.

Learn more about Harness Cloud & AI Cost Management or explore implementation guides.

Making Cost Optimization a Sustainable Engineering Practice

The long-term solution to cloud cost accountability for developers isn't better dashboards or more training. It's making cost a first-class operational concern, measured and optimized with the same rigor as latency and error rates. This requires infrastructure that surfaces cost data in real time, allocates it to responsible teams, and enforces governance through automation rather than manual review.

Organizations that treat cost as an afterthought end up with runaway cloud bills and adversarial relationships between engineering and finance. Organizations that embed cost visibility into platform workflows build sustainable practices where optimization happens continuously, not during quarterly cost reduction sprints.

Start by instrumenting your infrastructure for accurate cost allocation. Then integrate cost data into the tools engineers already use. Finally, implement automated guardrails that enforce governance without blocking velocity. The result is a platform where cost-aware engineering becomes the default, not the exception.

If your platform team spends more time investigating cost anomalies than preventing them, it's time to rethink your approach. Engineer cloud cost awareness doesn't fail because developers don't care. It fails because the infrastructure for accountability doesn't exist yet.

Engineer Cloud Cost Awareness: Why It Fails & Fixes

July 23, 2026

Technical

Time to Read

You receive an alert at 3 AM: your AWS bill for last month exceeded projections by 340 percent. Strategic cloud cost management wasn't on anyone's roadmap until finance demanded answers at the board meeting. Now platform engineering owns cloud spend optimization with no baseline, no tagging strategy, and three different teams provisioning infrastructure using five different methods. This scenario repeats across organizations that treated cloud costs as an operational afterthought rather than a strategic capability requiring the same rigor as security or reliability.

The shift from reactive cost monitoring to strategic governance represents a fundamental change in how engineering and finance collaborate on infrastructure decisions. Organizations that master this evolution gain predictable spending patterns, accelerate delivery velocity, and align technical decisions with business outcomes. Those that don't end up trapped in a cycle of emergency cost reviews and manual cleanup exercises that never address root causes.

The Reactive Cost Management Trap

Most platform teams begin their cloud journey with reactive approaches: monthly invoice reviews, spreadsheet-based tracking, and ad hoc optimization sprints triggered by finance escalations. This model breaks down at scale because it treats symptoms rather than causes. Engineering teams provision resources without visibility into cumulative impact. Finance teams flag overruns weeks after the spending occurred. Nobody owns the relationship between architecture decisions and their financial consequences.

The reactive model creates three operational failure modes. First, delayed visibility means optimization efforts target historical patterns that may no longer reflect current workload behavior. Second, the absence of cost accountability at the service or team level eliminates the feedback loop that drives sustainable spending discipline. Third, manual cleanup exercises address waste without preventing its recurrence, turning cost optimization into an endless cycle of fire drills rather than a continuous governance capability.

Organizations operating in reactive mode typically discover problems through monthly invoice shock rather than proactive monitoring. By the time finance raises flags, the spending has already occurred across dozens of services, multiple accounts, and various teams. Reconstruction efforts consume engineering cycles that could have prevented the overrun in the first place. The real cost isn't just the wasted cloud spend but the opportunity cost of diverting senior engineering time toward historical forensics.

Strategic Cloud Cost Management as Operational Discipline

Strategic cloud cost management treats financial accountability as a prerequisite for sustainable scale rather than a constraint on engineering autonomy. This requires real-time visibility into spending patterns, clear ownership boundaries at the service level, and automated guardrails that prevent common waste patterns before they compound. The goal isn't cost reduction for its own sake but alignment between technical architecture, delivery velocity, and business growth.

Organizations that implement strategic approaches shift accountability closer to provisioning decisions. Development teams receive cost feedback during sprint planning rather than months later. Platform teams establish governance policies that auto-scale resources based on actual utilization patterns. Finance teams gain predictive models that reflect engineering roadmaps rather than extrapolating from incomplete historical data. This shared ownership model eliminates the adversarial dynamic where engineering maximizes flexibility and finance minimizes spending without coordination.

The strategic model requires architectural patterns that support cost attribution and optimization at scale. Tagging strategies must extend beyond compliance requirements to enable meaningful cost allocation by service, team, environment, and business unit. Resource provisioning workflows must include budget validation before deployment. Monitoring systems must correlate performance metrics with spending patterns to identify efficiency opportunities. These capabilities don't emerge from one-time initiatives but from treating cost governance as a continuous operational discipline embedded in delivery workflows.

The FinOps Maturity Model and Cloud Cost Governance Framework

The FinOps maturity model provides a structured path from reactive monitoring to strategic optimization. The crawl phase establishes baseline visibility: accurate tagging, centralized reporting, and basic cost allocation. Organizations at this stage focus on understanding where money goes rather than optimizing spending patterns. The walk phase introduces accountability: team-level budgets, anomaly detection, and policy-based controls. The run phase integrates cost optimization into engineering culture: automated right-sizing, predictive modeling, and continuous improvement cycles tied to business metrics.

Most organizations stall between crawl and walk phases because they treat FinOps as a finance initiative rather than a platform capability. The transition requires engineering investment in governance frameworks, automation tooling, and cultural change management. Finance teams must learn enough about cloud architecture to ask meaningful questions about spending patterns. Engineering teams must accept that cost accountability enhances rather than constrains their ability to deliver value. Leadership must recognize that strategic cloud cost management requires dedicated platform engineering capacity, not just policy documents.

Cloud cost governance frameworks establish the boundaries within which teams operate autonomously. Policy-based controls prevent common mistakes: untagged resources, orphaned volumes, oversized instances, and unused reservations. Budget alerts create feedback loops before spending exceeds projections. Recommendation engines surface optimization opportunities based on actual utilization patterns. These guardrails enable decentralized decision-making while maintaining organizational visibility and control.

Enterprise Cloud Cost Optimization Tactics

Effective optimization starts with visibility into where spending occurs and why. Cost allocation by service, team, and environment reveals patterns that aggregate reporting obscures. A single service consuming 40 percent of infrastructure spend might represent legitimate scale or architectural inefficiency, but you can't distinguish between them without granular attribution. Tagging strategies must capture both organizational structure and technical context to enable meaningful analysis.

Right-sizing recommendations fail without workload context. An instance running at 15 percent CPU utilization might be oversized or might be handling bursty traffic that requires headroom. Automated policies that resize based purely on average utilization can create reliability issues during traffic spikes. Strategic optimization correlates utilization patterns with performance requirements to identify safe opportunities without introducing operational risk.

Reserved capacity and savings plans require predictive modeling grounded in engineering roadmaps rather than historical extrapolation. A three-year commitment based on last quarter's spending patterns becomes waste if architecture changes eliminate the underlying workload. Effective reservation strategies align commitment levels with stable baseline capacity while maintaining flexibility for variable workloads through on-demand and spot instances.

Cost anomaly detection provides early warning for spending deviations before they compound into invoice surprises. Automated alerts trigger investigation when daily spending exceeds expected patterns by threshold percentages. The key is tuning sensitivity to catch meaningful anomalies without generating alert fatigue from normal workload variance. Organizations that implement anomaly detection reduce time to detection from weeks to hours.

FinOps Best Practices and Cloud Financial Management Evolution

Sustainable FinOps practices embed cost accountability into delivery workflows rather than treating it as a separate governance exercise. Sprint planning includes budget impact assessment alongside feature requirements. Code review processes validate that infrastructure changes follow cost optimization guidelines. Deployment pipelines block resource provisioning that violates policy constraints. These practices transform cost management from a reactive cleanup exercise into a proactive design consideration.

Cross-functional collaboration between engineering, finance, and platform teams eliminates the information asymmetry that creates adversarial dynamics. Regular FinOps review meetings surface spending trends, discuss optimization opportunities, and align on priority trade-offs. Engineering teams explain architectural decisions that drive cost patterns. Finance teams provide business context that helps prioritize optimization efforts. Platform teams demonstrate how governance capabilities support both engineering velocity and financial discipline.

The evolution from reactive to strategic cloud financial management doesn't happen through big-bang transformations but through incremental capability building. Organizations start with basic visibility, add accountability mechanisms, implement automation guardrails, and gradually shift culture toward cost-conscious architecture. Each phase builds on previous capabilities while addressing the next constraint blocking maturity progression.

Harness Cloud Cost Management: Strategic Optimization at Scale

Harness Cloud & AI Cost Management implements strategic cost governance as an integrated platform capability rather than a standalone tool. The system provides real-time visibility into cloud spending across AWS, Azure, and GCP with cost allocation by service, team, environment, or business unit. This granular attribution enables accountability at the level where provisioning decisions occur rather than aggregating everything into organizational totals that obscure individual team impact.

Automated anomaly detection identifies spending deviations before they compound into monthly surprises. Budget tracking correlates actual spending against projections with alert thresholds tuned to organizational tolerance. Policy-based governance guardrails prevent common waste patterns: untagged resources, orphaned storage, oversized instances, and unutilized reservations. These controls maintain organizational standards while preserving team autonomy for legitimate architecture decisions.

The platform surfaces optimization recommendations grounded in actual utilization patterns rather than generic best practices. Right-sizing suggestions consider workload characteristics and performance requirements to avoid creating reliability issues while reducing waste. Reserved capacity planning integrates with engineering roadmaps to align commitment levels with predicted baseline capacity. The recommendations prioritize opportunities by potential impact to focus engineering effort on changes that drive meaningful savings.

Integration with broader delivery workflows embeds cost accountability into existing processes rather than requiring separate governance exercises. Cost feedback appears in planning tools, code review systems, and deployment pipelines where architecture decisions occur. Platform teams establish policy boundaries that auto-scale resources based on utilization patterns while maintaining budget controls. This integration transforms cost optimization from a monthly cleanup exercise into a continuous operational discipline.

Organizations implementing Harness CCM reduce time to cost visibility from weeks to minutes, shift accountability from centralized finance teams to distributed engineering teams, and replace manual cleanup sprints with automated governance that prevents waste before it occurs. The system supports the full FinOps maturity progression from basic visibility through strategic optimization without requiring teams to stitch together multiple point solutions.

Building Strategic Cost Management Capability

The transition from reactive monitoring to strategic governance requires sustained investment in three areas: technical capability, organizational process, and cultural change. Technical capability includes tagging infrastructure, implementing monitoring systems, and establishing automation guardrails. Process change embeds cost accountability into planning, development, and deployment workflows. Cultural change shifts engineering mindset from viewing cost governance as a constraint toward recognizing it as an enabler of sustainable scale.

Organizations that treat this transition as a finance initiative fail because engineering teams lack context for optimization decisions. Organizations that treat it as purely an engineering initiative fail because financial accountability remains disconnected from provisioning decisions. Success requires genuine collaboration where engineering teams gain visibility into business impact and finance teams develop sufficient technical literacy to ask meaningful questions about architecture trade-offs.

Strategic cloud cost management doesn't eliminate spending growth but aligns it with business value creation. Infrastructure costs should scale with customer growth, feature delivery, and revenue expansion. The goal is predictable, attributable spending where every dollar maps to a specific business outcome rather than accumulated waste from poor governance. Organizations that achieve this alignment accelerate delivery velocity because cost accountability becomes a design consideration rather than a post-deployment surprise.

The maturity progression from reactive to strategic cloud financial management represents a fundamental operational capability that differentiates organizations scaling cloud infrastructure sustainably from those trapped in cycles of emergency cost reviews and manual cleanup. Platform teams that invest in governance frameworks, automation tooling, and cross-functional collaboration eliminate the false choice between engineering velocity and financial discipline. The result is cloud infrastructure that scales efficiently with business growth while maintaining predictable spending patterns aligned with strategic objectives.

Learn more about strategic cloud cost management capabilities at Harness Cloud & AI Cost Management. Explore implementation details and governance patterns in the technical documentation. Review upcoming optimization features on the product roadmap.

Strategic Cloud Cost Management: Evolution Guide

June 9, 2026

Technical

Time to Read

Your Harness pipelines, logs, and deployment approvals are now a sidebar panel away inside VS Code.

The Harness VS Code Extension is live on the VS Code Marketplace today, no .vsix download, no manual install. Search "Harness" in the Extensions view, and you're a click away from real-time CI/CD visibility without leaving your editor.

Screenshot related to: The Harness VS Code Extension is live on the VS Code Marketplace today, no .vsix download, no manual install.

Everything Software Delivery in One Panel

Capability	What it does
Pipeline monitoring	Live status for active runs, with automatic git context detection, executions for your current branch and commit surface automatically.
Log viewer	Click any pipeline step to open its logs in a dedicated editor tab, syntax-highlighted. Failed steps are flagged immediately.
Inline approvals	Approve or reject Harness native, Jira, and ServiceNow deployment gates directly in the editor. No navigating to the UI.
AI-assisted debugging	Ask IDE-integrated Cursor, GitHub Copilot, or Claude about a failure. Pipeline context (name, status, execution ID, URL) is injected automatically. No copy-pasting.

Ask Your AI. It Already Has the Context.

When a pipeline fails, the default loop is: open Harness UI, find the execution, read the logs, copy the relevant output, open your AI assistant, paste, and ask. That's four context switches before you've started fixing anything.

The extension collapses that into one step. An input sits at the bottom of the Harness panel. Type your question, select Claude Code, GitHub Copilot, or Cursor from the dropdown, and the extension packages the current execution context automatically before sending.

‍

Screenshot illustrating: Ask Your AI. It Already Has the Context.

‍

What makes the context useful, not just present, is the Harness Software Delivery Knowledge Graph. The Knowledge Graph is a structured data model that connects every entity across your SDLC: pipelines, services, deployments, environments, artifacts, policy results, and more. When the extension sends your AI tool the execution context for a failing pipeline, it's pulling from that graph. So Claude Code, Copilot, or Cursor isn't just reading a raw log dump. It's receiving structured, relationship-aware data about what ran, what it depends on, and where it broke. That's the difference between an AI that can technically answer a question about your pipeline and one that can accurately answer it.

‍Claude Code responses appear directly in the Harness sidebar (CLI mode) or open the Claude Code panel with the prompt pre-loaded (extension mode). Click Configure MCP in the AI footer to wire up your Harness credentials: project scope or global, your choice.

‍GitHub Copilot is auto-detected when the extension is installed. Context and prompt open in Copilot Chat, ready to go.

‍Cursor is auto-detected when you're running inside Cursor. For the simplest setup, install the Harness plugin from the Cursor marketplace. OAuth authentication, no manual configuration.

Install in Two Minutes

Install:

Open the Extensions view (Ctrl+Shift+X), search "Harness", and click Install. Or from the terminal:

code --install-extension harness-inc.harness-vscode

Connect your account:

Click the Harness icon in the Activity Bar → run Harness: Configure API Key → enter your instance URL and Personal Access Token. Your Account ID is extracted from the PAT automatically.

Select your org and project. Pipelines load immediately.

‍Requirements: VS Code 1.85.0+, active Harness account.

Watch it in action

Watch the walkthrough from our very own Luis Redda.

Stay in VS Code. Your Pipelines Will Follow.

The context-switching loop (open Harness, find the execution, copy the log, switch to your AI tool, paste, and ask) doesn't have to be part of how you work. Pipeline status, logs, approvals, and AI-assisted debugging all live in the same panel as your code. Install the extension, connect your account, and the next time something breaks, you'll already be where you need to be.‍

For more information, checkout the docs.

From Commit to Approval, Without Leaving VS Code

June 1, 2026

Partners

Time to Read

AI agents are only as good as the context they operate in. That's not a design philosophy. It's a practical constraint. An AI agent that doesn't understand how the underlying software delivery entities relate to each other, or what the data actually means, will get things wrong. In software delivery, wrong looks like a botched deployment, a misread failure, or an approval granted when it shouldn't have been, which directly affects your users.

Today, we're announcing that the Harness MCP Server is in the official Claude Connectors Directory, making Harness discoverable and connectable for every team using Claude. But the announcement isn't really about the directory listing. It's about what Harness + Claude can actually do in your delivery system.

Screenshot related to: Today, we're announcing that the Harness MCP Server is in the official Claude Connectors Directory, making

What You Can Do with Claude and Harness

Claude can work across the full Harness delivery platform:

Capability	What Claude can do
Pipeline execution	Trigger and monitor builds across GitHub, GitLab, Bitbucket, or Harness Code
Deployment management	Promote services across environments with approval gate verification
Failure diagnosis	Pull structured execution context and surface root cause analysis
Approval workflows	Retrieve pending approvals and take governed delivery actions
Environment state	Query what's deployed where, in real time
Security posture	Review SBOMs, vulnerability scan results, and SSCA compliance status
Resilience testing	Initiate chaos experiments and retrieve structured results
Cost signals	Surface cloud cost anomalies tied to deployment activity

‍

Screenshot illustrating: What You Can Do with Claude and Harness

All of it is grounded in the Knowledge Graph, not raw API responses, but a structured model of your delivery system that Claude can reason over precisely.

The Problem With Giving AI Agents Raw API Access

MCP lets AI models call external tools by reading API descriptions and deciding which to invoke. That flexibility is useful. But when you're building an agent that needs to reason across an entire software delivery lifecycle, CI, CD, security scans, approvals, feature flags, cost signals, and environments, raw API access creates a deep reliability problem.

Consider a question a platform engineering lead might ask:

‍"Show me the pipelines with the highest failure rate over the last 30 days, and for each one, tell me which services they deploy and whether any of those services have open critical vulnerabilities."

That question spans four domains: pipeline execution history, service-to-pipeline relationships, environment state, and security scan results. An agent working off raw APIs has to discover which APIs exist across each domain, call them in the right order, paginate correctly, infer how field names correspond across systems, and synthesize the results without misinterpreting nested objects or guessing at relationships.

The result is 5+ sequential LLM calls, hundreds of thousands of input tokens, high latency, and an agent that had to guess at every join. Guessing is where hallucinations happen.

What the Harness + Claude Integration Changes

The Harness Software Delivery Knowledge Graph is a purpose-built model of everything that happens after code is written: builds, test runs, deployments, approvals, security scans, environment states, feature flags, infrastructure changes, cost signals, and rollbacks. Not as raw data but as a connected, typed, semantically annotated graph of entities and relationships.

Every field in the graph carries metadata that tells an agent exactly how to use it: whether a value is a number or a string, whether it can be aggregated or only filtered, what its unit is, and how it joins to related entities. Cross-module relationships, between a pipeline and the services it deploys, between a deployment and the security scan results for that artifact, between an environment change and the cost anomaly that followed, are explicitly declared, not inferred.

This is the difference between an agent that can access your delivery system and one that understands it.

When Claude connects to Harness via MCP, it doesn't receive a set of API endpoints. It's getting access to a structured model of your entire delivery organization, one where the relationships are known, the data types are enforced, and the agent can construct precise queries rather than guessing at field semantics.

‍The practical effect with Harness + Claude: that same cross-domain question above becomes 2–3 structured queries against a known schema. The agent selects the right entity types from the graph, generates queries with exact fields and declared relationships, and returns a deterministic answer. No guesswork. No hallucinated field names. No silent wrong answers.

What This Looks Like in Practice

Debugging a failed pipeline without context switching

A build has failed. Normally, you'd open the Harness UI, navigate to the execution, copy the relevant logs, paste them into a conversation, and wait for analysis. The AI reasons over whatever you managed to capture.

With the Harness MCP connection active in Claude, you ask what failed. Claude doesn't just pull logs; it queries the Knowledge Graph to understand the structure of that pipeline, which stage failed, what services were involved, whether similar failures have occurred before, and what changed since the last successful run. The answer it surfaces reflects the full delivery context, not just the stack trace you happened to copy.

Screenshot illustrating: Debugging a failed pipeline without context switching

Promoting a deployment through governed gates

Your team is ready to move a service from staging to production. Claude checks the current environment state, verifies that required approval gates have been satisfied, confirms the security scan passed for the artifact version you're promoting, and initiates the deployment — with every action running through your existing RBAC policies and logged for audit.

The agent isn't guessing about whether conditions are met. It's querying a graph where those conditions are modeled as typed relationships with known states. The answer is deterministic because the data is structured to make it so.

This Is Not AI Without Guardrails

The natural question when Claude can trigger pipelines and manage deployments: what stops it from doing something it shouldn't?

The same controls that govern everything else in Harness. Every action taken through the MCP server runs through your existing RBAC permissions, OPA policy enforcement, approval gates, and audit logging. Claude operates with exactly the permissions you have, nothing more. Every action is tracked. Nothing bypasses the governance layer.

The Knowledge Graph reinforces this: because Harness AI understands your delivery system structurally, it also understands the constraints within it. Approval gates aren't just optional steps the agent might skip; they're modeled as typed relationships with state. The agent can't promote past a gate that hasn't cleared because the graph reflects that clearly.

Speed and governance aren't a tradeoff. They coexist by design.

Why the Claude Connectors Directory Matters

The Claude Connectors Directory is a curated, reviewed set of integrations. Anthropic evaluates each server before listing it. Being approved is a signal of trust that carries weight for enterprise teams deciding which AI integrations to enable.

It also means discoverability at scale: engineering teams using Claude for DevOps workflows will find Harness natively. One-click OAuth connection, no API key management, no manual configuration.

This fits a broader pattern. The Google Cloud partnership brought Harness into Google's AI ecosystem through Vertex AI and Gemini CLI. The Cursor plugin brought it into the IDE. The Claude Connectors Directory brings it into conversational AI. In each case, the goal is the same: wherever developers are doing their best thinking and wherever AI is being asked to help with software delivery, Harness should be present with the right context for that AI to act reliably.

Getting Started

If you're already a Harness customer:

Open Claude and then the Connectors page
Search for Harness in the MCP directory
Authenticate with OAuth, no API keys, no manual configuration
Start asking Claude about your pipelines, deployments, and delivery workflows

If you're new to Harness, sign up for free and connect from day one. Detailed steps are listed in the documentation.

The Harness Connector gives Claude the ability to act in your delivery system. The Knowledge Graph gives it the understanding to act well. Together, that's what reliable AI in software delivery actually looks like.

Software Delivery Context, Now Inside Claude

May 28, 2026

Technical

Time to Read

The pace of AI spend has gotten ahead of most teams. New agents, new copilots, new flows powered by language models, all moving from prototype to production in weeks. Finance is often the first to flag it, because the data lives across provider invoices, gateway dashboards, observability tools, and cloud bills with no single source of truth. A small change to a prompt or a model can move spend by an order of magnitude. A retry loop in an agent can burn a month of budget in an afternoon.

Across customer and analyst conversations, the same questions keep surfacing. What are we spending on AI today, across providers and teams? How do we attribute that spend to the products, features, and customers driving it? At the unit level, not the invoice level, is each AI feature actually economical?

Today we're launching Harness Cloud & AI Cost Management, a new product that puts AI spend and cloud spend into the same system, with the same allocation, governance, and anomaly detection.

Cloud Cost Management has been part of Harness for years. Its primitives (cost categories, perspectives, budgets, anomaly detection) work because they meet teams where they already manage cloud. Cloud & AI Cost Management applies those same primitives to AI workloads and adds the granularity AI requires: session, agent, run, step, and individual LLM call. The deeper shift is unit economics. Every dollar of AI spend gets tied to the agent, session, and outcome it produced, so AI features can be evaluated by what they cost per outcome rather than what they show on the monthly invoice.

What ships today

AI Cost Economics Dashboard

Unit economics surfaced natively for measuring AI outcomes:

Cost per agent run
Cost per session, including multi-turn conversations
Cost per inference
Cost broken down by token type, session, inference, and use case
Agent ROI tied to business outcomes (cost per resolved ticket, cost per completed workflow, cost per customer interaction)

‍

Screenshot illustrating: AI Cost Economics Dashboard — SCREENSHOT: AI Cost Economics Dashboard, showing unit economics across agents and sessions

Cost by Provider

Unified visibility across native LLM providers and managed AI services. OpenAI and Anthropic for direct API spend. AWS Bedrock and GCP Vertex AI for managed services. Spend is normalized across providers, so comparisons and analysis don't require custom pipelines.

Cost by Model

Per-model and per-version cost tracking, with input and output token volumes, inference counts, and trends. Useful for evaluating model choice, watching the impact of a model upgrade, and identifying which models are growing fastest in spend.

Unit Economics by Agent

Cost attributed to AI agents, whether internal copilots, customer-facing assistants, or background automations. Inferences, session cost, token usage, and trends surfaced per agent so engineering and product teams can evaluate cost-per-outcome at the agent level.

Custom Unit Economics Using Cost Categories

Attribute AI spend to any customer-defined construct, including business unit, product line, customer tier, or feature. Built on the existing cost categories framework, so the rules teams have already written for cloud chargeback apply to AI spend with no extra setup.

Session and Conversation Level Granularity

Cost per session, cost per multi-turn interaction, and token composition broken down by call. This is the level of detail provider billing APIs can't give. A multi-turn conversation that costs four times an average session because the agent is looping through a tool chain becomes visible, attributable, and fixable.

Screenshot illustrating: Session and Conversation Level Granularity (image 2) — SCREENSHOT: Run Detail, showing a step-level cost waterfall for a single agent run

AI Cost Explorer

Filter and group AI spend by the dimensions that matter for AI workloads:

Provider, account, and project
Model and model version
Token type, including input, output, and cache reads and writes
Context type and inference profile, including standard, long context, and global routing
Region
Labels and custom dimensions

Drill from business-level metrics down to raw cost data, with filters that compose the same way they do everywhere else in the product.

Screenshot illustrating: AI Cost Explorer — SCREENSHOT: AI Cost Explorer, with provider, model, and token-type filters applied

One platform for cloud and AI cost

Most AI cost tools are point solutions. They show AI spend in their own dashboards with their own allocation model. That's useful for visibility, less useful when you're trying to govern AI alongside the cloud spend driving the rest of your infrastructure bill.

Existing Harness Cloud Cost Management customers get something different. The chargeback rules, cost categories, and budgets already written for cloud spend now apply to AI workloads. AI cost becomes another allocation in the same system, not a parallel workstream to reconcile separately.

The depth also goes further than provider billing APIs allow. AI spend can be analyzed at agent, session, run, and step level, down to the model and tool invoked at each step. Worst-case behavior surfaces as itself rather than averaged into a monthly number, and the same dimensions plug into cost categories, perspectives, and budgets.

Getting AI cost into Harness

Three ingestion paths let teams adopt the depth that matches their stage. Provider connectors give fast unified visibility across OpenAI, Anthropic, Bedrock, and Vertex. Gateway integration adds per-request attribution. OpenTelemetry traces give full session and workflow detail. Most teams start with connectors and add depth as their AI footprint grows.

What this looks like in practice

A customer-support copilot might show $28,000 on a monthly invoice. That number alone doesn't tell you whether the bot is earning its keep. The more useful number is $0.60 per resolved ticket. And when a session costs $4 because the agent is looping through tools it shouldn't be using, that surfaces as a code problem you can fix, not a line item to explain after the fact.

Existing Cloud Cost Management customers can enable AI Cost Management today. For everyone else, request a demo.

‍

Cost Per Outcome: AI Cost Management in Harness

May 28, 2026

Technical

Time to Read

AI coding tools made code generation faster. Measuring what actually ships is the hard part.

Over the last eighteen months, tools like Cursor, Claude Code, Copilot, and Windsurf have fundamentally changed how software gets built. AI-generated pull requests are increasing, developers are producing more code than ever before, and workflows that once took hours now happen in minutes. But most organizations struggle to clearly explain what that investment is actually producing.

Only a fraction of AI-generated code ultimately survives review and reaches production, yet engineering leaders still lack visibility into which coding agents improve delivery performance and which workflows simply contribute to tokenmaxxing with no clear ROI.

That gap exists because traditional engineering systems were built for a world where development started with a commit. But AI fundamentally changed where the software development lifecycle begins. Development no longer starts with a commit. It starts with a prompt. The model choice, token consumption, generated code, review cycles, deployments, and production outcomes are now all part of the same engineering workflow. Measuring only what happens after code is committed is no longer enough.

That shift is what led Harness to evolve Software Engineering Insights into AI DLC Insights, to help organizations measure how AI-generated work moves through the entire development lifecycle from prompt to production.

Three questions every engineering organization is trying to answer

These three operational gaps exist inside almost every team running AI at scale today:

Are we more productive? Seats don't equal usage, and usage doesn't equal productivity. But most teams still cannot draw a clear line between AI investment and engineering output.
Are we spending efficiently? Leaders need to know how much spend produced shipped code versus how much was wasted on uncommitted sessions, wrong model choices, and missed cache opportunities.
Are we shipping better products faster? Faster code generation does not automatically mean better products. Leaders must measure how AI impacts code quality, security vulnerabilities, and quality regressions.

These three gaps are exactly what AI DLC Insights is organized around. Together, they give engineering leaders a complete picture of what AI is producing inside their engineering organization, from the first prompt to the last deployment.

Adoption: See exactly how AI is being used

The first question starts with understanding what AI adoption actually looks like at the team and individual level. Seat counts and API usage aggregates give you a surface view. Understanding whether AI-generated code is actually making it into production requires something deeper.

Most engineering systems were never designed to observe AI-assisted development workflows directly. Source control can show what was committed. Billing systems can show token consumption. Neither can explain which generated code actually survived review, reached production, or improved delivery performance.

That is why AI DLC Insights introduces a new Agent that runs directly inside the developer environment. The agent observes AI interactions in real time, captures AI-generated code, tracks token consumption across coding agents and models, and connects that activity directly to commits, pull requests, deployments, and production outcomes.

Screenshot illustrating: Adoption: See exactly how AI is being used

‍

What that makes visible:

AI Code Percentage: See exactly how much shipped code was AI-generated, broken down by developer, team, or repository.
AI-Assisted PRs & Commits: Track the percentage of merged PRs and commits containing AI-attributed code to measure real adoption growth.
Active Users & Agent Breakdown: See which tools (Cursor, Claude, Windsurf, Copilot) engineers actually rely on to produce committed code.
Power User Identification: Surface engineers with high AI commit velocity to understand winning patterns and scale them across the org.

Efficiency: Know where every AI dollar is going

Developer token consumption is increasing every month, but most teams still cannot explain which workflows are producing production-ready code and which are simply burning tokens.

That gap exists because token spend and engineering outcomes typically live in completely separate systems. Finance teams can see the monthly invoice, while engineering teams can see sprint activity and pull requests. Connecting token consumption directly to shipped code, deployment velocity, and engineering throughput is still difficult for most organizations.

As tokenmaxxing behaviors emerge, activity can easily be mistaken for impact. Some workflows generate meaningful production-ready code and improve delivery throughput, while others consume enormous amounts of tokens without improving what actually ships.

Screenshot illustrating: Efficiency: Know where every AI dollar is going

‍

AI DLC Insights closes that gap, breaking down spend by developer, team, agent, and workflow:

Wasted Spend: Spot tokens burned in sessions that produce no committed code (e.g., a developer generates output in Cursor but closes the session without saving) to eliminate unproductive workflows.
Optimizable Spend: Catch inefficient patterns—like using an expensive frontier model for a simple task, suffering low cache hit rates, or having high turn counts on basic prompts—to restructure workflows and stretch your budget.
Cost Per Work Item: Correlate session costs with issue trackers to calculate the exact AI spend required to close a backlog item, ship a feature, or resolve an incident.

Impact: Measure AI-generated code in production

Adoption and efficiency are inputs. Impact is the output. And the output is not lines of code generated or tokens consumed. Its features shipped, bugs resolved, lead time reduced, security posture improved, and customers getting better software faster.

More AI-generated code does not automatically produce those outcomes. Without the right visibility, AI adoption can quietly produce the opposite: more code volume with more review burden, more complexity with more regressions, faster generation with slower delivery cycles. The organizations that catch those patterns early are the ones that maintain quality as velocity increases.

Screenshot illustrating: Impact: Measure AI-generated code in production

‍

AI DLC Insights connects AI activity to the delivery metrics that reveal what is happening downstream:

Features Delivered & Backlog Reduction: Compare teams at different adoption levels to see if higher AI usage actually translates to more shipped features.
PR Velocity & Lead Time: Track if PRs are merging faster. High open rates combined with low merge rates indicate AI is increasing the review burden, not reducing it.
DORA Metrics: Out-of-the-box tracking for deployment frequency, change failure rate, lead time, and MTTR to ensure AI adoption correlates with delivery health.
Business Alignment: Map engineering output directly to executive priorities to prove where your investment is going.

The next phase of engineering visibility

The first generation of engineering analytics platforms measured software delivery after the commit. The next generation will measure how humans and AI systems build software together.

Boards are no longer asking whether engineering teams are using AI coding tools. They’re asking whether the investment is improving software delivery in measurable ways. Whether teams are shipping more production-ready code. Whether delivery metrics are moving alongside token consumption. Whether the spend is generating real engineering leverage or just increasing the invoice.

Answering those questions requires visibility into how AI-generated code actually behaves across the full development lifecycle, from the prompt that created it to the deployment that shipped it.

That is what AI DLC Insights was built to deliver.

Ready to prove the ROI of your AI engineering investment? Request a demo to learn more.

Cost Management Agent Blogs

Featured Blogs

Software Delivery Context, Now Inside Claude

What You Can Do with Claude and Harness

The Problem With Giving AI Agents Raw API Access

What the Harness + Claude Integration Changes

What This Looks Like in Practice

Debugging a failed pipeline without context switching

Promoting a deployment through governed gates

This Is Not AI Without Guardrails

Why the Claude Connectors Directory Matters

Getting Started

Latest Blogs

The Reactive Trap: Why Traditional FinOps Misses the Mark

Cloud Cost Savings Strategy: Building a Proactive Framework

FinOps Best Practices: Accountability Beyond Finance

Maximize Cloud Savings Through Preventive Optimization

Harness CCM: Engineering Proactive Cloud Cost Optimization

Moving from Reactive to Proactive FinOps

FinOps Savings Optimization: Stop Overspending, Start Saving

Why Traditional Cloud Cost Visibility Breaks Down

1. Cloud Cost Allocation Challenges Multiply Fast

2. Multi-Cloud Environments Create Fragmented Visibility

3. Reactive Reporting Comes Too Late

How to Restore Cloud Cost Visibility at Scale

1. Automate and Deepen Cost Allocation

2. Use Context-Aware Anomaly Detection

3. Make Governance Proactive, Not Punitive

How Harness Cloud Cost Management Supports Visibility at Scale

Unified Cost Visibility Across Clouds and Kubernetes

Cost Allocation That Matches Real Ownership

Context-Driven Anomaly Detection

Governance That Enables Speed

Visibility Creates a Cost-Aware Engineering Culture

Why Cloud Cost Visibility at Scale Fails (And How to Fix It)

Cloud Asked What It Cost, AI Is Asking What It's Worth

What Does Developer Productivity Actually Mean for Your Team?

Are You Measuring Activity or Outcomes?

Where Are Your Team Productivity Measurement Blind Spots?

What Percentage of Your Engineering Capacity Goes to Unplanned Work?

How Long Does It Take to Get Feedback on Code Quality?

Are Your Engineering Productivity Metrics Driving the Wrong Behavior?

Do You Understand the Relationship Between Developer Experience and Business Outcomes?

How Does Harness SEI Answer These Questions?

Connecting the delivery data

Measuring delivery performance

Visualizing workflow trends

Adapting metrics to your organization

Understanding how engineering effort is spent

Turning visibility into better decisions

The Questions Lead to Better Answers

Boost Developer Productivity: 8 Key Questions

The Real FinOps Paradigm Shift: From Cost Control to Value Creation

Why Traditional FinOps Cost Optimization Frameworks Miss the Target

The Foundation: You Can’t Optimize What You Can’t Attribute

Proactive Cloud Cost Management Starts Before Deployment (Not After the Invoice)

Beyond Dashboards: Always-On Systems That Never Sleep

Cloud Cost Governance Best Practices That Scale with Teams

Engineering Economics: Making Optimization Everyone’s Job

How Harness Cloud Cost Management Enables Proactive FinOps Savings Optimization

Harness CCM strengthens FinOps savings optimization through:

The Path Forward: From Cost Cutting to Systematic Under-Saving Recovery

What To Go Deeper?

You're Not Overspending, You're Under-Saving: A New FinOps Paradigm

Why Traditional Cloud Cost Optimization Approaches Fail

The Reactive Cycle That Perpetuates Cloud Cost Optimization Challenges

Building a Cloud Cost Governance Framework That Scales

Implementing a Sustainable Cloud Cost Management Approach

How Harness Cloud Cost Management Enables Governance at Scale

Establishing Sustainable Cloud Cost Optimization Best Practices

Cloud Cost Optimization Strategy: Fix Your Approach

Why Engineering Team Cost Visibility Fails at Scale

Cloud Cost Governance for Engineers Needs Guardrails, Not Guidelines

The Incentive Misalignment Problem

Building Cost-Aware Engineering Practices That Scale

What Cost Accountability for Developers Actually Looks Like

How Harness CCM Embeds Cost Awareness Into Platform Workflows

Making Cost Optimization a Sustainable Engineering Practice

Engineer Cloud Cost Awareness: Why It Fails & Fixes

The Reactive Cost Management Trap