notebook № 165 plates · 14 min to read, longer to play ·
Seeing the bill coming
On forecasts, budgets and surprises
part 6 of 7 in What the cloud costs · by Slavik Shynkarenko
A cloud bill moves every hour, but budgets are set once a year and reviewed once a month. Forecasting, budgeting and anomaly detection close that gap: a guess about next month that’s good enough to plan on, a budget that warns before it’s blown, and an alarm that rings on day one of a leak instead of day thirty.
plate I · forecasting methods
Three ways to guess next month
The simplest cloud forecast is the run rate: next month will cost what this month did. It’s easy, it’s usually where finance starts, and it breaks whenever anything moves, which in the cloud is constantly.
A trend line copes better with a growing bill, and a trend with seasonality copes better again. Most businesses have a shape to their year (a holiday peak, a summer dip, a campaign every spring), and a seasonal term is how the forecast learns it. A forecast that ignores the shape misses in the same direction every year.
Forecast quality is measured as variance: how far actual spend lands from the forecast. The FinOps maturity examples put the targets at 20% for a practice starting out, 10% walking, 5% running. Moving from one level to the next usually takes better method rather than better data.
Forecast the first half of the year with the run rate, then with trend and season. Which one survives January?
plate II · driver-based forecasting
Forecast the business, not the bill
Every method in plate I looks backwards. They can’t know that a new region opens in April, that marketing plans to double sign-ups, or that the platform team is halfway through a migration that cuts compute by a fifth.
A driver-based forecast can. It writes cost as a business volume times a unit cost: users times cost per user, orders times cost per order. Product and finance forecast the volume, engineering forecasts the unit cost, and launches and migrations go in as explicit lines.
It’s more work than a trend line, and it’s the kind of forecast that turns into a conversation: if spend comes in high, you can see whether the business grew or the efficiency slipped. Finance’s top-down number (“last year plus ten percent”) can’t tell you either.
Raise user growth to 4% a month with no efficiency work. Then add 20% efficiency. Which line does finance’s guess match?
plate III · budgets and alerts
Budgets that warn early
A cloud budget is a forecast with a limit attached: this team, this month, this much. Every provider lets you set one and alert at thresholds, typically 50%, 80% and 100%.
The catch is what the alert compares against. An alert on actual spend tells you the budget is blown once it’s blown. An alert on forecast spend projects the month-end from the current rate, and warns while there’s still time to act, often weeks earlier.
Budgets also need an owner and a reason. A budget per team, fed by allocation, turns an alert into a message to the people who can change the number. A budget nobody owns is just a chart with a red line.
Switch from “alert on actual” to “alert on forecast”. How many days earlier does the 100% alert fire?
plate IV · anomaly detection
Spotting the spike
An anomaly is spend nobody expected: a runaway job, an agent stuck in a loop, a misconfigured autoscaler, a forgotten load test, a leak that grows a little every day. The sooner a leak is caught, the less it costs, which is why every major cloud now ships anomaly detection next to its budgets.
The naive detectors fail in opposite ways. A fixed threshold misses everything below it and fires every busy Monday. A day-over-day rule panics after every weekend. An expected range, learned per weekday from recent weeks, catches both spikes and slow leaks with far fewer false alarms.
Then comes the trade-off nobody escapes: sensitivity. Tighten the range and you catch more, along with noise. Loosen it and the alerts go quiet, until the leak is three weeks old. The right setting is the one where every alert gets read.
Try the fixed threshold, then the expected range. Slide sensitivity until the leak is caught without false alarms.
plate V · variance analysis
Explaining the miss
At the end of the quarter, actual spend never matches the budget. The question finance asks is why, and “the cloud got more expensive” doesn’t count as an answer.
Variance analysis splits the gap into causes: volume (the business grew and usage grew with it), rate (discounts or prices moved), new work (something launched that wasn’t in the plan) and anomalies (money that shouldn’t have been spent at all). Each cause has a different owner and a different fix, and some of them are good news.
This is where the rest of FinOps pays off. Allocation says whose cost it was, unit economics separates volume from efficiency, the rate team can show its savings, and the anomaly log explains the rest. An overspend you can explain line by line is a planning input.
Open the explained view and click each bar. Which of the causes would you want more of?
Questions people ask
- How accurate should a cloud cost forecast be?
The FinOps Foundation’s maturity examples measure forecast variance against actual spend: within about 20% for a practice starting out, 10% for a developing one and 5% or better for a mature one. Accuracy improves most when forecasts use seasonality and business drivers, and when engineering, product and finance all feed into them.
- What is driver-based cloud cost forecasting?
Driver-based forecasting models cost as a business volume times a unit cost: for example active users times cost per user, or orders times cost per order. You forecast the drivers with product and finance, the unit cost with engineering, and multiply. It catches changes a trend line can’t, like a launch, a migration or an efficiency project.
- How does cloud cost anomaly detection work?
It learns the expected spend for each service, account or team, usually by day and accounting for weekly patterns, and flags days that fall outside the expected range. Good systems catch spikes and slow leaks, tune sensitivity to keep false alarms rare, and route each alert to the team that owns the cost so someone acts the same day.
Related material
elsewhere in the notebooks
further reading
- Forecasting FinOps Foundation The Framework capability, with its forecast-variance measures.
- Budgeting FinOps Foundation Setting, tracking and adjusting cloud budgets.
- Anomaly Management FinOps Foundation Detecting, routing and resolving unexpected spend.
- Forecasting: Principles and Practice Rob J. Hyndman and George Athanasopoulos The free textbook on time-series forecasting: trend, seasonality and how to measure error.