FinOps Schedule Recommendations Now Show Evidence, Not a Guess
A single fixed 50KB threshold decided whether a resource counted as “quiet.” Every account got the same number, regardless of that resource’s own traffic. That definition quietly broke. Schedule recommendations stopped appearing for most accounts, not with an error or a warning, just an empty section where recommendations used to show up. Nothing in the product said a detection path had failed.
FinOps is the practice of giving engineering, finance, and product teams shared, real-time visibility into cloud cost so spending decisions get made where the usage happens. Schedule recommendations are one of that practice’s more direct levers: a resource that’s genuinely idle overnight doesn’t need to bill for the overnight hours. It’s fixed now, and recommendations are flowing again. The failure mode is still worth understanding, because it wasn’t a crash. It was a threshold that had quietly stopped matching reality for most of the accounts checking against it.
A Fixed Quiet-Network Threshold Breaks the Moment Baselines Differ
The detection logic behind a schedule recommendation asks a specific question: is this resource’s network activity quiet enough, often enough, to justify proposing a stop-start schedule. The old version of that question used one fixed number as the definition of “quiet,” applied the same way to every resource regardless of its own baseline traffic. A resource that normally runs busy still counts as “quiet” relative to itself at 2 a.m., but a single fixed threshold can’t express that. It can only ask whether traffic dropped below one number that has no relationship to what normal looks like for that specific box. Non-prod VMs left running 24x7 are exactly the resources a fixed threshold is worst at catching, because their traffic pattern looks nothing like a production box’s.
The fix replaces the fixed number with a relative one: a resource counts as quiet when its network-in traffic drops below the greater of a 50KB floor or a quarter of that resource’s own 90th-percentile traffic. That threshold now applies in both places the platform checks for idle windows, and the Azure-specific path picked up an additional guard that abstains from a recommendation entirely when a resource is 95% or more idle, rather than proposing a schedule for something that’s barely running at all.
| Threshold model | What “quiet” means | What breaks |
|---|---|---|
| Fixed absolute threshold | Network-in below one fixed number, same for every resource | A naturally busier resource never reads as quiet, even overnight; a naturally quiet one can misfire |
| Relative threshold (this fix) | Below 50KB or 25% of the resource’s own p90, whichever is greater | Scales to each resource’s own baseline instead of assuming one baseline for everything |
Already-Stopped Hours Don’t Count as New Savings
A separate piece of the fix handles resources that are already stopped for part of the week. Those hours are tracked as a distinct category, not folded into the “quiet” measurement, rendered off in the evidence view and excluded from the idle-percentage calculation entirely. That distinction matters because a resource that’s already stopped ten hours a day has nothing to gain from a recommendation to stop it during those same ten hours. Counting already-stopped time as new savings would overstate every recommendation touching a resource with any existing downtime, and the fix specifically rules that out. The same pass added two Azure regions, southindia and westindia, to the map that resolves a region to its timezone, and kept a zero-value fallback that preserves the old absolute test for anyone who had tuned around it directly.
The Redesigned Drawer Shows Evidence Instead of Asking for Trust
The recommendation panel itself was redesigned around the same idea: show the evidence, don’t just assert the conclusion. A weekly utilization view now places activity at the actual hours it happened, one column per day, instead of a single generic bar meant to represent an average day that may not resemble any real one.
The before-and-after transition strip is drawn directly from the recommendation’s own proposed schedule, not a separately imagined “typical day.” If the evidence doesn’t support a clean before/after picture, the strip degrades honestly instead of drawing a fragmented day that doesn’t correspond to anything the resource actually did. That’s a deliberate constraint: a chart that always looks clean, even when the underlying data doesn’t support it, is worse than no chart at all, because it borrows credibility the data hasn’t earned.
The Savings Number Now Matches What Apply Actually Does
The last piece closes the gap between what a recommendation promises and what clicking Apply actually creates. Savings are now priced directly off the cron schedule that would be applied, using a start-only buffer and a pre-shift window bound, rather than an idealized version of the schedule that looks better on the card than it performs in production.
This works when the proposed schedule is the one that actually gets applied unmodified. It breaks if someone edits the schedule after seeing the recommendation and before clicking Apply, since the savings figure was priced against the original proposal, not a hand-edited one. The same discipline applies to savings the account is already capturing. Those never get re-counted as new. A recommendation that already reflects reality is worth less as a headline number and worth more as something you can act on without re-verifying it first.
