Blog

Runtime FinOps: From Action to Consequence to Learning

Simon Mestdagh
January 12, 2026
January 12, 2026
•
3
min read

FinOps is missing its runtime layer

We didn’t start TRU+ to boost individual cloud cost optimization actions.

We started it because FinOps is missing its runtime layer.

‍

Most cloud cost tooling still lives in planning:

  • Budgets
  • Forecasts
  • Estimates
  • Policies

All valuable — and all disconnected from what actually happens in production.

‍

Security went through this exact transition a decade ago.

FinOps hasn’t yet.

‍

A lesson from security: shift to runtime

Around 2016–2019, security teams realized something uncomfortable.

Pre-merge checks couldn’t keep up with:

  • Cloud infrastructure
  • Containers
  • Continuous deployment

The system moved faster than prediction.

‍

Why pre-merge security broke down

Pre-merge feedback was:

  • Hypothetical
  • Abstract
  • Easy to ignore

Developers saw warnings, not consequences.

And without consequences, there was no learning.

‍

What changed security

Security evolved when teams moved into runtime.

They stopped trying to catch everything before merge and instead:

  • Let changes ship
  • Observed real production behavior
  • Attached outcomes to Git identity
  • Gave feedback once impact existed

‍

From “This could be risky" to “This change caused this incident”

‍

That was the birth of runtime security.

And it worked because it closed the loop: Action → consequence → learning

‍

‍

FinOps is still stuck pre-runtime

Today, FinOps is where security used to be. Cost feedback is:

  • Delayed
  • Aggregated
  • Detached from change

Bills arrive weeks later. Context is gone. Ownership is unclear.

‍

Engineers rarely see how their change affected cost in production.

So cost remains something that happens to teams, not something they learn from.

‍

‍

Runtime FinOps: our core idea

TRU+ is built around a simple belief: You can’t manage cloud cost without observing it at runtime.

Runtime FinOps means:

Not optimizing from spreadsheets.

Learning from reality, directly in the engineering workflow.

‍

‍

How Runtime FinOps works in practice

‍

1. Start at runtime, not planning

We begin after deploy:

The goal isn’t enforcement. It’s evidence.

‍

2. Make cost a system with memory

Over time, the system learns:

  • Which code changes consistently increase cost
  • Which patterns don’t matter
  • Which trade-offs are intentional

Cost stops being a monthly surprise and becomes: “When we do this, it costs that.”

That understanding didn’t exist before runtime visibility.

‍

3. Move left — but only after learning

Only once runtime evidence exists does moving left make sense.

Pre-deploy feedback becomes: “We’ve seen this pattern in production. Last time it led to +€X/month.”

This isn’t prediction. It’s memory.

Low noise. High trust.

‍

4. Guidance instead of gates

In Runtime FinOps:

  • Pre-merge signals guide decisions
  • Defaults get safer
  • Learning accelerates

Nothing is blocked. DevOps velocity stays intact.

‍

‍

Accountability emerges at runtime

We don’t impose accountability as a process.

It appears naturally when:

No blame. No detective work. Just clarity.

‍

‍

Why savings are a side effect

When teams understand runtime cost impact:

  • They fix what they break
  • They stop repeating expensive patterns
  • They make better trade-offs

Savings happen — but they’re not the point.

‍

Just like in security, the goal isn’t “fewer alerts.”

It’s better systems, with more and smarter control.

‍

‍

The shift FinOps needs

Security matured when it moved into runtime.

FinOps will mature the same way.

Runtime FinOps closes the loop between action, consequence, and learning — for cloud cost.

That’s the product vision behind TRU+.

‍

We don’t provide savings dashboards.

We build the runtime layer FinOps has been missing. And savings are what follow.

Subscribe to newsletter

Subscribe to receive the latest on TRU+

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.