Act on a cost finding

Turn an optimization-hunter finding into a defendable, executed saving — without leancosts ever touching your cloud.

1. Find the opportunity

Findings surface in two converged places, both fed by the same hunter fan-out:

Opportunities (/opportunities) — the daily landing and your team’s shared decision-of-record. Open findings, cost anomalies, and savings in flight all live here. It has two tabs: Triage (the findings) and Ledger (the signed change requests). A savings funnel at the top shows, at a glance, what you’ve identified → put in flight → executed → realized (plus a capture rate and the open claim as a % of last month’s spend — how much of the bill is still optimizable, falling as you act), and how many findings you’ve accepted, set aside (Not now), or permanently rejected (Won’t fix).
Hunters hub (/hunters) — a savings-portfolio overview, then per-category pages (Compute, Database, Storage, Network, Observability & AI, Integration) plus the standalone SQL-Migration hunter.

Low-confidence candidates are withheld by default — leancosts ships fewer, trustworthy numbers rather than a wrong one. Each finding carries an estimated monthly impact and a confidence score.

Most findings are savings (the bill goes down). Opportunities also surfaces a small set of cost-adds — right-size-ups: a resource starved under sustained load that should grow before it becomes an incident. These are a justified cost increase, tracked through the same lifecycle. Use the Type filter (Savings / Cost-adds) to focus on one or the other; cost-add rows are marked + $X/mo · review-only so you can never confuse a debit with a saving. The headline number stays savings-only; committed cost-adds show on their own line.

A third kind of row is a cost anomaly — an unusual spike (or drop) versus a service’s usual monthly level. An anomaly is an alert to investigate, not a saving to claim: its amount is money already spent above the baseline, so it never counts toward your savings numbers. Its detail view says so — a single “Spike vs. baseline” figure instead of the claim tiles — and the action is Acknowledge (you’ve seen it and looked into it), not Accept. Use the Variance Explainer to find out what moved.

On any finding you can Accept it (then draft a change request), set it aside with Not now (it comes back if the cost or usage materially worsens), or Won’t fix it permanently (it never re-surfaces). When several findings are the same kind, “Act on all N similar findings” drafts one change request that covers all of them — one approval instead of many.

2. See who owns what

Ownership is per-finding, and the Ownership strip above the list rolls it up for the whole team: one row per person plus an Unassigned bucket, against To do, Doing, and Done (the last 90 days). Each cell shows how many findings and how much monthly claim sit there; click one to filter the list to that person and stage, click again to clear.

Assign from the list row itself (or from a finding’s detail view) — the assignee is a picker of your organization’s members, so one person is always one bucket. Cost anomalies and cost-adds are counted in a person’s cells but never added into a claim figure, because neither is a claimable saving.

3. Draft a change request

Every finding’s primary action drafts a change request (CR) — the signed ledger entry that makes the action auditable. You can draft a CR from:

a hunter finding (one CR, or “Act on all N similar” for one CR across the group),
the Copilot (when an answer is an actionable saving, it shows “Draft a change request”), or
an Auto-Remediation Playbook — per-category vetted CR templates, in the Ledger tab’s Playbooks panel (/change-requests). A playbook card also offers “Draft one CR for all N”, which covers every candidate of that playbook in a single change request — one approval for the whole fleet. Candidates that fail their safety check are left out and listed with the reason, and a candidate that already has a change request in flight is never offered twice.

The CR is created in draft status with a written rationale, a scope, and the estimated monthly impact (negative = savings, positive = a justified cost-add).

When you draft a CR from a right-size-up (cost-add) finding, leancosts asks you to name the target SKU / tier to grow to — it deliberately does not pick a size for you, because “how much bigger” is your call. The CR then carries a positive (cost-increase) impact built around the SKU you chose.

4. Submit → approve (dual control)

The CR lifecycle is draft → submitted → approved → executed:

Submit the draft. Approval is per-kind — a tag-only approver sees tag CRs to approve, an infra approver sees infra CRs.
An approver in the allowlist (someone other than the author) signs off. The signatures + rationale become the audit trail that later explains why a month’s variance moved.

5. Apply the change yourself

leancosts never mutates your cloud. For tag changes it produces a guided CLI kit (az tag, aws resourcegroupstaggingapi, gcloud); for infra changes it records the decision. You run the change in your own environment, then mark the CR executed with the date.

Run it on a schedule instead of by hand

Once a change request is approved, its detail view offers an execution bundle: the approved change packaged as one bash script you run with your own credentials, in your own environment. leancosts generates the text — it holds no write access to your cloud and never runs anything.

The script is self-documenting and defensive:

a header with the change request id, the rationale, who approved it, and when the bundle was generated;
--dry-run — runs every check for real, prints the commands, changes nothing. Always start here;
--rollback — the documented revert. When a change is genuinely one-way the script says so and refuses rather than inventing an undo;
pre-flight guards that refuse to run (exit code 2) if the CLI is missing or signed out, if a resource the change was approved against has since disappeared, if a value the recipe left to you isn’t exported, or if the bundle has gone stale (older than 30 days by default — regenerate it).

Alongside the script you get one-shot scheduler templates — a crontab line, a GitHub Actions workflow, and an Azure DevOps pipeline — so you can pin the run to a change window. They schedule the change once; a change request is a single signed decision, so nothing here loops.

Reporting back (optional). By default the run prints a receipt and you mark the change request executed yourself. If you’d rather it stamped the request for you, generate a report-back token from the same panel and store it in your CI secret store as LEANCOSTS_RECEIPT_TOKEN. That token is not an API key: it is scoped to that one change request, it can only mark that one change request executed, it expires, and it is never written into the script or the templates. Re-running a job that already reported back changes nothing.

6. Prove the saving

Once executed, post the saving to the Realized Savings Ledger (sidebar: Savings): each claimed saving must trace back to its executed CR and a measured before/after cost delta. Claims without evidence cannot be posted. For the exact criteria a saving clears, see How we count a saving. The ledger behaves like a bank account — a realized right-size-up posts as a measured cost increase that nets against your savings, so the number finance sees is the honest total. The ledger then feeds the ROI line in your email digest and the Savings Register’s savings report.

Already fixed it yourself? Say so

You don’t have to go through a change request to get credit. When a scan stops detecting an opportunity, leancosts closes the row as auto-resolved — and, when the disappearance plausibly follows our recommendation, asks you one question. A banner on Opportunities reads “N opportunities were resolved — confirm how”; Review shows those rows, and each drawer offers two answers:

We applied this fix — the row is marked done and the saving is drafted into the ledger as a claim. It is a claim, not a posted saving: the same bill measurement grades it once the first full month after your fix closes.
Resolved independently — an unrelated change made it go away. Nothing is claimed. leancosts will not credit itself with a saving you say wasn’t ours.

The loop, end to end

hunter finding ─────────► draft CR ──► submit ──► approve ──► you execute ──► realized-savings ledger
 (Savings Register/Hunters)  (rationale + impact)  (dual control)  (guided CLI kit)   (evidence-backed)
        └──────────────────────► you already fixed it ──► confirm how ──► claim (measured from the bill)