Proof, not promises
Savings that count only once they hold
When GetFinOps stops or deletes a resource, the saving is booked as pending and re-checked in that AWS account about seven days later. Only changes that held count.
It doesn’t reconcile savings with your AWS invoice or Cost Explorer.
The problem
“Potential savings” is a number nobody can check. Finance can’t tell an estimate from a change that stuck, so a FinOps program struggles to show what it has actually saved.
How it works
Book
A stop or deletion succeeds, and its estimated monthly saving is recorded as pending, with a check due seven days later.
Re-check
A sweep every six hours picks up due rows and looks up each resource in its own account. EC2 stops still in place are checked again every 30 days.
Count
Changes that held add to realized savings. Reverted or rolled-back changes book zero, and a revert moves a self-running action type back to approve each.
7 days
or more after a change, before a re-check can count its saving as realized
Zero
booked for a reverted or rolled-back change
Never zero
for a resource that couldn’t be read: it’s retried, then marked unverifiable
30 days
between re-checks of stopped EC2 instances
Capabilities
Count a saving only after the change is looked up again in AWS and still holds.
Booked when a change succeeds
Stopping an EC2 or RDS instance, or deleting an EBS volume or snapshot, books its estimated monthly saving as pending when the execution succeeds. Tag changes and security fixes save nothing directly, so they aren’t booked.
Re-checked in the right account
About seven days later, the resource is looked up again with the cross-account role of the account the change ran in. If the lookup fails, it’s retried a day later rather than recorded as zero.
A verdict for every change
Still stopped, or gone, counts as verified. Running again or recreated counts as reverted, and a change GetFinOps rolled back counts as rolled back; both book zero. A stopped RDS instance counts for seven days at most, and a resource that can’t be looked up is eventually marked unverifiable.
Totals you can scope
Realized savings add up verified and time-capped rows only, shown next to the estimate with counts of verified and pending checks. Pick a cloud account to scope them, or read the same summary through the MCP server.
In depth
Which changes are booked
A ledger row is created when an execution succeeds, for the action types that save money by staying in place, and only when the estimate is above zero. The row records the estimate, the account, the resource and a check date seven days out.
Adding tags and turning on S3 Block Public Access don’t save money directly, so they aren’t booked. Neither are rightsizing or commitment purchases, which GetFinOps doesn’t run. Re-running the same execution never books a second row or overwrites a verdict.
- Stopping an EC2 instance.
- Deleting an unattached EBS volume.
- Deleting an EBS snapshot.
- Stopping an RDS instance, which is supported though no finding proposes it yet.
How the re-check works
A background sweep runs every six hours. It takes the rows that are due, looks up each resource with the cross-account role of the account the change ran in, and records a verdict with the date it was measured.
If AWS throttles the lookup, the role is denied or there’s no live AWS connection, the row is tried again a day later. If it still can’t be read 14 days after its check was due, or its account is gone or has no role to assume, it is marked unverifiable. A resource that couldn’t be read is never recorded as reverted or as zero.
Deletions are checked once, because a deleted volume or snapshot stays deleted. An EC2 instance that is still stopped is checked again every 30 days.
The verdicts
Realized savings add up verified and expired rows only. Pending and unverifiable rows are left out of the realized total rather than counted as zero, so the gap between estimated and realized shows what isn’t proven yet. Each verdict also records how many days the change had held when it was measured.
- Pending: booked but not checked yet.
- Verified: the instance is still stopped or no longer exists, or the volume or snapshot is gone. The estimate counts in full.
- Reverted: the instance is running again, or the resource exists again. Counts as zero.
- Rolled back: GetFinOps undid the change after it was booked. Counts as zero.
- Expired: an RDS instance was still stopped seven or more days after the stop. Counts as a prorated seven days.
- Unverifiable: the resource couldn’t be looked up for 14 days after its check was due, or its account is gone or has no role to assume. Left out of realized savings.
Where you see it
The Executions page shows realized savings per month next to the estimate, with counts of verified and pending checks. Each execution shows its own status, and a row that hasn’t been measured reads “not yet verified” instead of showing $0. The account overview shows the verified realized figure too. Choose a cloud account in the header to scope the totals, or ask for the same summary through the MCP server.
Every verdict is also written to the audit trail with the execution, the status and the realized figure.
How it feeds autonomy
The ledger is evidence for the autonomy ladder. A saving found reverted moves that action type, in that account, back to “approve each” if it was running on its own. Reverted and rolled-back rows from the last 30 days also stop the action type from graduating.
What it does not do
- It doesn’t reconcile savings with your AWS invoice or Cost Explorer. Figures are estimates at AWS list price for changes that held.
- It doesn’t reflect Savings Plans, Reserved Instances or other discounts, so a realized figure can be higher than what you actually save.
- It doesn’t track tag changes, security fixes, rightsizing or commitment purchases.
- It doesn’t cover GCP, where GetFinOps makes no changes.
- It doesn’t count a resource it can’t read. After 14 days of failed checks, or at once if the account is gone or has no role to assume, the row is marked unverifiable and left out.
FAQ
Questions
How is a saving verified?
By looking the resource up again. If an instance is still stopped, or a volume or snapshot is gone, the estimated monthly saving counts as realized. If the resource is running again or exists again, it counts as zero.
Is this reconciled with my AWS bill?
No. Realized savings are list-price estimates for changes that held. They aren’t reconciled with your invoice or Cost Explorer, and they don’t reflect your discounts.
What if someone restarts the instance later?
Stopped EC2 instances are re-checked every 30 days. If one is running again, it’s recorded as reverted and no longer counts toward realized savings.
Why does a stopped RDS instance count for seven days at most?
AWS starts a stopped RDS instance again after seven days. A stop still in place at the check counts as a prorated seven days of the monthly estimate, and it isn’t checked again.
Try free — no credit card
Create a workspace and connect an AWS or GCP account, or book a demo first.