From finding to fix
How an approved finding becomes a Terraform pull request, a runbook, or a Jira ticket, and how the savings ledger tracks it from identified to verified.
A findings list is not savings. Savings happen when somebody makes a change, and the gap between those two things is where most cost programs quietly stall. This page describes what CloudIQ does about the gap.
Approval comes first#
Nothing changes in your environment until a person decides it should. There is no automatic remediation and no "auto-apply low-risk changes" mode. The one exception is optional BigQuery reservation automation, which is off by default.
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 for an audit looks exactly like one kept by accident.
Where an approved finding goes#
| Path | What ships | When it is the right path |
|---|---|---|
| Terraform pull request | About 40 templates (18 AWS, 21 Google Cloud), bundled weekly, with the evidence in the description. The code matches resources you already manage in Terraform | The fix is a change to infrastructure code |
| Runbook | Step-by-step instructions with rollback steps, from 28 AWS runbook catalogs, exportable as PDF | The fix is operational rather than declarative: a snapshot and delete, a tier change, a cleanup |
| SQL rewrite | An optimized query for engineer review | A BigQuery query pattern |
| Jira ticket | The resource, condition, evidence, estimated saving and proposed change, assigned to the owner. Status syncs back to the task | Any finding, on its own or alongside a pull request |
Prefer a pull request where it applies. A change made in the console is undone the next time Terraform applies the old configuration.
Several findings that are one piece of work (twelve unattached volumes in one account) are grouped into one ticket rather than twelve. Twelve tickets for one afternoon's work is how a backlog stops being read.
Slack digests and email reports carry findings and status changes on a schedule you set. They are notification paths, not approval paths. Approving happens in the platform.
The savings ledger#
| Stage | Meaning |
|---|---|
| Identified | A check found it and priced it |
| Assigned | It has an owner |
| In progress | The change is being made |
| Completed | The owner marked the work done |
| Verified | A later audit no longer finds the condition, and later billing data confirms the effect where available |
Estimated amounts exist from the moment a finding does. Verified amounts exist only after a completed task passes a later audit. The two are never merged and never annualized, and finance-ready exports report them by stage. A bill that falls the month after a cost program starts has many explanations, most of them seasonal. Tying a saving to a specific completed task is the only claim that survives a finance review.
If a change causes a problem#
Every task carries a rollback plan, a risk level and a confidence rating. Terraform changes can usually be reversed with a standard Git revert. Actions that cannot be reversed cleanly say so and state the recovery steps. Most teams start with low-risk changes in non-production and expand from there.
What a healthy program looks like#
Not one large drop. A steady stream of completed tasks, each small and attributable, with the estimated backlog shrinking faster than new findings arrive. If new findings arrive faster than they close, find out early. It usually means new infrastructure is being built the expensive way.
Next#
Try this against your own spend
The free Cloud Cost Assessment switches on your billing exports with you and takes a read-only snapshot. You get more than 30 insights and your top savings ranked by dollars a month.