Capacity planning has a reputation for being either a spreadsheet ritual done once a quarter or a panicked reaction to the latest outage. Neither works well for modern cloud systems, where demand shifts with product launches, marketing campaigns and seasonal patterns, and where the cost of overprovisioning is as real as the cost of running out. Forecasting, done carefully, gives teams a middle path.
The first lesson is to forecast the right quantity. Raw utilisation of a single host is a poor target because it changes whenever the scheduler moves workloads around. Prefer demand-side signals such as requests per second, queue depth, active sessions or batch volume, and translate them into resource needs using measured ratios, for example CPU cores per thousand requests per second. This separates the question of how much work is coming from the question of how efficiently the system handles it, and lets you reason about each independently.
Seasonality is the next challenge. Most services show daily and weekly cycles, plus occasional events that break the pattern. Classical methods such as seasonal decomposition and exponential smoothing handle the regular cycles well and are easy to explain. More flexible models can capture holidays and trend changes, but they need more history and more care. A sensible practice is to start with the simplest model that beats a naive baseline, such as repeating last week, and add complexity only when it measurably improves forecast error on held-out data.
Uncertainty belongs in the output. A single predicted line invites false confidence, while a forecast with an interval lets you plan for the likely case and the bad case separately. Provision to the upper bound for critical services where running out is costly, and to the median for batch work that can tolerate delay. Reporting the interval also makes it obvious when the forecast is unreliable, for instance right after a launch when there is little history to learn from.
Anomaly detection and forecasting work best together. When live demand departs sharply from the forecast, that is either a genuine surge needing action or an incident, such as a retry storm, inflating traffic. An agent can compare the deviation with recent deployments, upstream errors and client behaviour before recommending scale-out. Distinguishing real demand from self-inflicted load prevents the expensive mistake of scaling up a system that is actually failing.
Autoscaling is not a substitute for planning. Reactive scaling handles minutes-scale changes but is limited by startup time, quotas, regional capacity and the budget. Forecasts should feed scheduled scaling for predictable peaks, reservation or commitment purchases for the stable baseline, and quota requests made well ahead of launches. Teams that rely only on reactive scaling often discover their limits during the exact event they hoped to handle.
Close the loop by tracking forecast accuracy as a service-level metric of its own. Measure error by horizon, review the largest misses and record what caused them. Use language models for what they do well, such as summarising the weekly capacity report, explaining why a forecast changed and drafting the justification for a capacity request, while leaving the numerical forecasting to proven statistical tools. The goal is not a perfect prediction. It is a process that makes surprises smaller, rarer and cheaper.