What Finitizer looks for

A finding is the unit of work in Finitizer. Everything else on the platform exists to produce findings, prioritise them, or track them to done.

What a finding contains

Every finding answers five questions, and it is not a finding until it answers all five.

The fourth and fifth are where most cost tooling stops short. A number with no method behind it cannot be argued with, and an engineer being asked to change production will, rightly, want to argue with it.

Concretely, a finding reads something like this:

Resource   vol-0a1b2c3d4e5f  (eu-west-1, account 4471…9082)
Condition  Unattached EBS volume
Evidence   Detached since 2026-05-02 (103 days). No snapshot taken since
           2026-04-28. 500 GiB, gp3.
Saving     $40.00 / month  (direct: the volume stops existing)
Action     Snapshot, then delete. Terraform: aws_ebs_volume.scratch_02

The Evidence line is the part that matters. It is what turns "the tool says delete this" into a claim the owner of that volume can check in under a minute — and checking it is exactly what you want them to do.

What a finder is

A finder is one rule, looking for one condition, in one service. Narrowness is the design: a rule that tries to detect "waste" in general produces findings nobody trusts, while a rule that detects "an NLB with no healthy targets registered for 14 days" produces one that is either true or false and can be checked in a minute.

Finders fall into a few families.

Idle and orphaned

Resources that are running, billing, and doing nothing. Unattached EBS volumes, load balancers with no targets, idle RDS instances, NAT gateways in subnets with no outbound traffic, provisioned endpoints with no invocations.

These are the cheapest findings to act on, because there is nothing to preserve.

Over-provisioned

Resources doing real work, on more capacity than the work needs. Instance rightsizing, volume type and IOPS changes, cache node sizing, cluster scaling floors.

These need a utilisation window long enough to include the peak. A rightsizing recommendation built on a quiet week is how you get paged.

Structurally wrong

Resources whose configuration costs money for no benefit: storage in a class that does not match its access pattern, data crossing a boundary it need not cross, a backup retention policy nobody chose.

Commitment and rate

Spend that is correct in volume but priced worse than it could be — coverage gaps in committed-use discounts and reservations, on-demand usage that has been steady for a year.

BigQuery and data platform

Query patterns that scan more than they return, tables that would cost less partitioned or clustered, storage sitting in active pricing long after anyone last read it.

How savings are estimated

Every estimate carries the method that produced it, because the methods differ in confidence and pretending otherwise is dishonest.

• Direct: the resource stops existing, so the saving is its current run rate. An unattached volume is the clearest case.
• Differential: the resource changes shape, so the saving is the difference between two prices — gp2 versus gp3 at the same size, one instance family versus another.
• Modelled: the saving depends on behaviour that has to be projected — commitment coverage, scheduling a workload off out of hours.

Direct estimates are close to certain. Modelled ones are ranges, and they are presented as ranges.

Savings are also not claimed as realised until the change is actually made and the platform has measured the difference. An estimated saving and a realised saving are tracked as two different numbers, on purpose. Most of the disappointment in this category comes from tools that conflate them.

Prioritisation

Findings are ranked by estimated saving, but that is not the whole picture: the platform also carries effort and risk, because a $400/month saving behind a change nobody is willing to make is worth less than a $200/month one that ships this afternoon.

The practical advice for a first pass: take everything in the idle and orphaned family first. It is the largest single bucket in most accounts, and none of it requires a conversation about performance.