Why most cloud cost tools show you a guess — and what we do instead
Ask most cloud cost tools how much a dev VM running 24/7 is wasting, and you'll get something like "stopping this off-hours saves ~65%." That number usually isn't computed from your actual schedule — it's a flat constant baked into the product, applied to every VM regardless of what "off-hours" means for that specific resource.
We built CloudOptimizer AI's analyzer that way too, originally. Then a customer caught a recommendation showing an estimated ₹5,461/month savings for an AKS cluster that, on inspection, had zero real cost data behind it at all — the number was a placeholder that had never been overwritten with anything real. That's what triggered a full rewrite of how every number on the dashboard gets computed.
The bug hiding in "typical" percentages
Two specific problems compound each other in the flat-percentage approach:
- The percentage itself is fiction. "65% off-hours savings" assumes a specific shutdown window. A schedule that actually stops a resource 19:00–08:00 on weekdays plus all of Saturday and Sunday saves an exact, computable 67.26% of a 168-hour week — not a round number, and not the same for every schedule.
- The base price can be wrong by 10×. We found this directly: Azure's Retail Prices API returns both
ConsumptionandReservationpricing entries that can share the same meter name. A naive "pick the most recently effective price" query grabbed a Reservation-tier entry for a premium disk — $2,953/month — when the real pay-as-you-go price was $259.05/month. Anything downstream of that price, including a "conservative-looking" percentage applied on top of it, inherits the error.
The two errors don't cancel out — they compound. A flat percentage applied to a wrong base price produces a confident-looking number that's wrong on both axes, and nothing in the UI signals that to the customer. It just looks like a real recommendation.
What we replaced it with: three honest states
Every recommendation in CloudOptimizer AI now carries one of three states, and the UI renders each one differently so a customer can tell at a glance how solid a number actually is:
| State | What it means | Example |
|---|---|---|
| Precise | Real observed cost from the cloud's own billing API × an exact, computed percentage | A disk's actual last-month cost, deleted entirely |
| Priced | No billing history exists yet, so the figure comes from the cloud's live retail pricing API instead | A brand-new VM with no cost history, priced from Azure's current rate for that SKU |
| Unquantified | Neither exists — shown with no ₹ figure at all, not a smaller guess | "This cluster needs an environment tag before we can classify it automatically" |
There's no global rescaling step anymore either. The old model capped total savings at 70% of the bill whenever the raw total "looked too high" — a uniform shrink applied after the fact, on top of numbers that were often already wrong. Once every number traces to something real, an arbitrary cap on top of it isn't defensible, so we removed it.
What this costs us
Being honest about what's unquantified means the dashboard sometimes shows fewer priced recommendations than a competitor's flashier "you're wasting 40%!" banner. We think that's the right trade — a number a customer can verify against their own Azure portal is worth more than a bigger number they can't.
Free scan, no card required — every number traces back to your real billing data or Azure's live pricing.
Run a free scan →