Why Your Cloud Cost Tool Keeps Telling You to Delete Active Resources

If you have spent any time inside a cloud cost platform, you have probably hit this moment: a flashy "save $18/month" card recommends deleting a storage account, you click in to verify, and the same tool tells you the resource is actively in use. Same resource. Same panel set. Opposite verdicts. You close the tab a little less trusting.

This is not a bug in one product — it is a category-wide failure mode. Here is how it happens, and the structural fix every cost tool should adopt.

The bad inference: absence of metrics ≠ unused

Most cost tools score "orphan likelihood" by reading whether they could find recent activity metrics for a resource. For a virtual machine that is fine: CPU and network are always there. For storage accounts, key vaults, role definitions, and dozens of other resource types it is not: those services do not expose transaction metrics by default, and the tool reads the silence as "nobody uses this."

Your platform team does. Your billing system does. Your audit pipeline does. The metrics endpoint just was not turned on.

When the LLM behind the recommendation engine sees "no transaction metrics available" in its prompt, it does the most human thing possible: it assumes the worst and recommends deletion. The Quick Actions card shows up. The MSP shows it to a client. The client gets nervous about the tool.

The structural fix: one canonical verdict, every surface

The right model is to keep two ideas separate:

• The scanner verdict — "is this resource in use?" — is the source of truth. It can be UNUSED (positive evidence of zero activity), IN_USE (the scanner confirmed it is active, with or without telemetry), or UNKNOWN (we genuinely do not have enough data to call it).
• The recommendation engine — only generates a destructive action ("delete") when the canonical verdict is UNUSED. Anything else gets routed to a non-destructive action ("review", "investigate").

Crucially, the absence of metrics is never evidence of disuse. If the scanner has explicit data, it states it. If it does not, the verdict is UNKNOWN and the platform should say so — not invent confidence it does not have.

Once that distinction exists, every UI surface — the Quick Actions card, the AI Recommendations panel, the resource-detail explainer, the exported MSP report — has to consume it. The Quick Actions card cannot show "delete this" when the same resource is going to show "in use" on the next click. The two surfaces are sharing one function call, not one Slack channel of hand-coordinated heuristics.

What this looks like inside CloudRift

CloudRift's verdict-consistency module produces a single `compute_verdict()` call that every surface — recommendations, detail panels, account telemetry, exported reports — routes through. A delete recommendation that contradicts the scanner verdict is downgraded automatically by a sanitizer that runs at generation time AND on read; cached recommendations from older generations cannot leak destructive advice. Action text is sourced from the same explainer that the detail panel renders, so the prose matches across panels — not just the verdict.

There is even an admin telemetry endpoint that walks every account and reports any cross-surface contradiction. If the same resource ever gets opposite verdicts again, it pages oncall before any customer sees it.

The bigger lesson

Cloud cost tools live on trust. The first time a customer catches you recommending deletion of an actively-used production resource, they stop trusting the next thirty recommendations — even the right ones. The fix is not "tune the heuristic" — it is structural agreement between every surface that takes a position on a resource.

If your current platform has ever told you to delete something you are using, ask it where its canonical verdict lives. If the answer is "in the LLM prompt," that is the bug.