From finding to fix

A findings list is not savings. Savings happen when somebody makes a change, and the gap between those two things is where most cost programmes quietly die.

This page describes what Finitizer does about that gap.

Approval comes first

Nothing leaves the platform until a person decides it should. There is no automatic remediation, no "auto-apply low-risk changes" mode, and no scheduled action that takes effect while nobody is looking.

The reason is not caution for its own sake. It is that the platform can be confident a volume is unattached and still be wrong about whether it matters — because the one thing it cannot see is intent. A snapshot kept deliberately for an audit looks exactly like one kept by accident.

Where an approved finding goes

Jira

A finding becomes a ticket carrying the account and resource, the condition found, the evidence, the estimated monthly saving, and the proposed change.

Tickets are created in the project and issue type you configure, and the platform keeps their status in sync: when the ticket is closed, the finding moves with it.

Where several findings are genuinely one piece of work — twelve unattached volumes in one account — they are grouped into a single ticket rather than twelve. Twelve tickets for one afternoon's work is how a backlog stops being read.

Infrastructure as code

When a fix is expressible as a change to infrastructure code, the platform can open a pull request against your repository instead of, or as well as, a ticket.

This is the better path where it applies, for a reason worth stating plainly: a change made in the console is a change your Terraform will revert on the next apply. Fixing cost in the console while the source of truth still describes the expensive shape is work that undoes itself.

The pull request carries the same evidence as the ticket, in the description, so the reviewer is not being asked to trust a diff on its own.

Slack and email

Findings, digests and status changes can be delivered to Slack channels or by email, on a schedule you set. This is a notification path, not an approval path — approving still happens in the platform.

Estimated versus realised

The platform tracks two numbers and never lets them merge.

Estimated saving is what a finding is worth if it is acted on. It exists from the moment the finding does.

Realised saving is what actually changed after the work was done. It is attributed only when the task workflow says the change was completed, and it is measured, not inferred from the bill moving.

That distinction matters more than it sounds. A bill that goes down the month after a cost programme starts has many possible explanations, most of them seasonal. Attributing the drop to the programme is flattering and usually wrong. Tying a saving to a specific completed task is the only claim that survives scrutiny from a finance team.

What this looks like over a quarter

The shape of a healthy programme is not one large drop. It is a steady stream of completed tasks, each small, each attributable, with the estimated backlog shrinking faster than new findings arrive.

If new findings are arriving faster than they are closed, that is worth knowing early — and it is usually a signal about how infrastructure is being created, not about the cost programme itself.