Last week, our own cost optimization tool told us to delete a load balancer that was very much in use.

It had served roughly 6,300 requests over the previous 14 days. It had listeners, target groups, healthy targets, and live traffic. Fintropy flagged it as “unused.”

We caught it because the load balancer in question was ours - fintropy-aws-alb, running in our own dev environment. That is the good news, and it is also the point: we run our own scanner against our own infrastructure, and dogfooding is what surfaced the bug before a customer ever saw it.

Here is what happened, because it is a trap that any cloud cost tool can fall into.

Two speeds of scanning

Fintropy scans in tiers. Tier-1 is a deterministic, fast pass built for breadth: it inventories your resources and evaluates structural rules without making the expensive, rate-limited calls that deep metrics require. Tier-2 goes deeper and pulls actual utilization data from CloudWatch.

For load balancers, the 14-day request count comes from CloudWatch. In a Tier-1 scan, we skip that call by design. And here was the mistake: when we skipped it, the collector left request_count_14d = 0 as a placeholder.

A placeholder that lied

Our “Unused Load Balancers” rule is simple and reasonable on its face. If a load balancer has no traffic, it is a candidate for removal. So the rule looked at request_count_14d, saw 0, and did exactly what it was told: zero traffic means unused, so flag it as waste.

# the rule, before
if lb.request_count_14d == 0:
    flag(lb, reason="no traffic in 14 days")  # but 0 might mean "never measured"

The problem is that the 0 did not mean “no one is using this.” It meant “we did not measure this.” Absence of a measurement had been silently promoted to a measurement of absence.

Why this class of bug matters more for FinOps

Every tool has false positives. But the cost of a false positive is not the same everywhere.

If a monitoring dashboard mislabels something, you double-check and move on. If a cost tool tells you a live load balancer is waste, and someone trusts it, they delete a piece of production infrastructure to save a few dollars a month. The savings are trivial. The outage is not.

In FinOps, a confident wrong answer that says “delete this” is far more expensive than a missed saving. That asymmetry is exactly why correctness here is not optional.

The fix

The fix is small once the problem is named correctly.

The collector now emits an explicit metrics_available flag: false when metrics were skipped or unmeasured, true when they were actually pulled. The rule now trusts low traffic only when it was genuinely measured. When metrics were not measured, it falls back to structural signals instead: no listeners, no target groups, no registered targets or instances. Those are real evidence of an orphaned load balancer, and they do not depend on a number that was never collected.

# the rule, after
if lb.metrics_available:
    unused = lb.request_count_14d == 0          # a real, measured zero
else:
    unused = (not lb.listeners                  # structural evidence instead
              and not lb.target_groups
              and not lb.registered_targets)

We also added tests to lock the behavior in both directions: a Tier-1 placeholder no longer flags a fully configured load balancer, and a measured, genuinely low-traffic load balancer still gets flagged.

The principle

The engineering lesson is one I keep relearning in different costumes: absence of evidence is not evidence of absence.

A placeholder value is not data. The moment a “not measured” masquerades as a “measured zero,” every rule downstream inherits the lie. The durable fix was not a smarter threshold; it was making the distinction between measured and unmeasured explicit, and refusing to act on data we do not actually have.

If you build tools that recommend destructive actions, that distinction is the whole game.

Amit Jethva is the CTO and co-founder of Nuvika Technologies Pvt Ltd, makers of Fintropy, a multi-cloud FinOps platform. Learn more at nuvikatech.com.