Every FinOps platform can hand you a rightsizing recommendation. The hard part has never been getting the recommendation- it's deciding whether to believe it.
Waste isn't a cost claim. It's a utilization claim. "This instance is oversized" really means "this instance isn't using what you're paying for"- and you can't prove that from a bill. You need CPU. Network. Usage volume. The operational reality behind the line item.
Until recently, getting that proof meant leaving the FinOps tool: open CloudWatch or the Snowflake console, find the resource, pull the metrics, cross-reference timeframes against the recommendation. Recommendations died in that gap- not because they were wrong, but because verifying them was someone else's job in someone else's tool.
The new ability, in one line: Billy can now retrieve historical performance metrics- CPU, network, usage volume- for supported AWS, GCP, and Snowflake resources, directly in the conversation. The investigation happens where the recommendation lives.
Here's how we actually use it.
CostGuard flags an m5.2xlarge as oversized. Before, that recommendation went into a ticket and waited for an engineer to care. Now the follow-up is one question:
"Show me CPU and network for this instance over the last 30 days."
If CPU has been sitting under 10% with no meaningful network throughput, the conversation is over- that's not a recommendation anymore, it's a decision with a paper trail. Forward it to the owning team with the utilization data attached, and the conversation starts from evidence instead of "the tool says."
Same recommendation, different resource. Average CPU looks low- but you ask:
"What does the daily CPU pattern look like? Any spikes?"
Turns out the instance runs a nightly batch job that pins CPU for two hours. Averages hide that; the actual metric history doesn't. You just dismissed a bad recommendation in ninety seconds- and you didn't send it to an engineer who would have downsized the instance, watched the batch job fall over, and lost a little faith in every future recommendation.
False positives are the silent killer of optimization programs. Every bad recommendation that reaches engineering makes the next ten good ones easier to ignore. Filtering them out cheaply is worth as much as finding new waste.
A dev-environment instance has near-zero cost variance, month after month. Idle candidate- but "cheap and steady" isn't proof of anything.
"Has this instance served any network traffic in the last 30 days?"
Flat zero network plus flat-line CPU is the signature of a truly abandoned resource: safe to terminate, not just downsize. Intermittent blips tell you someone still touches it- so tag the owner and ask, instead of pulling the plug on someone's forgotten-but-needed sandbox.
A warehouse shows steady spend. Is it earning it?
"What's the usage volume on this warehouse over the past month?"
If query volume is a fraction of what its size implies- or usage clusters into two hours a day while spend is flat around the clock- you've got a concrete case for resizing or tightening auto-suspend. The spend line alone could never tell you that; spend looks identical for a warehouse that's busy and one that's just on.
The part everyone skips. The team downsized the instance two weeks ago- did it hold?
"Show me CPU on this instance since the resize."
If utilization settled into a healthy range, the savings are real and the case is closed- book them. If CPU is now pinned at 90%, you caught the over-correction before it became an incident. Either way, the optimization program stops running on faith: every action gets verified with the same tool that recommended it.
The pattern generalizes. A few we keep coming back to:
"Is this recommendation backed by actual utilization data?" "Compare CPU on this resource between last month and this month." "Which of these flagged instances actually has zero network traffic?" "Show me the usage pattern before I forward this to the team."
Ask, verify, act- in one conversation. No console access, no context switching, no knowing which of four monitoring tools holds the metric you need.
And that last part is the real unlock: who can run the investigation. When validation lives in monitoring consoles, waste investigation is engineering work- so the queue grows. When validation is a question in plain language, the FinOps practitioner runs the full investigation solo and arrives at engineering with evidence: "this instance has been under 10% CPU for six weeks, here's the pattern, here's the recommendation." That conversation closes.
A recommendation without evidence is an opinion. An assistant that can only talk about cost can only give you opinions. The moment it can show you how a resource actually behaves, it stops being a reporting layer and becomes the place where the investigation happens.
The bill tells you what you spent. The investigation tells you what you wasted. Billy now does both.
Want more prompts like these? Grab the Billy Cheat Sheet- a growing collection of the questions our best users ask, now updated with the new metrics-validation prompts.