Forecast Methodology
Overview
Cloud Ctrl provides forecasts for cloud spend, carbon emissions (CO₂e), and energy consumption (kWh). Forecasts are generated using time series decomposition, a well-established statistical technique that separates historical data into underlying patterns and then projects those patterns forward to predict future values.
This document explains, in technical terms, exactly how Cloud Ctrl generates forecast numbers.
What Gets Forecast
| Metric | Description |
|---|---|
| Spend | Projected cloud cost in the tenant's display currency |
| CO₂e | Projected carbon emissions (kilograms CO₂ equivalent) |
| kWh | Projected energy consumption (kilowatt-hours) |
Each metric can be forecast at the following levels:
- Overall — total forecast across all cloud accounts in the tenant
- By Service — forecast broken down per cloud service (e.g., compute, storage, networking)
- By Subscription — forecast broken down per subscription
- By Product — forecast broken down per product/meter
All spend values are returned in the tenant's display currency, with currency conversion applied server-side before forecasting.
The Forecasting Method
Step 1: Historical Data Collection
The forecast is built from daily historical data covering the most recent 70 days of actual usage. This lookback window is fixed and provides the recent pattern the forecast model learns from.
The data is filtered by the tenant and any selected dimensions (cloud accounts, subscriptions, services, products, regions, tags, cloud provider, etc.) so that the forecast reflects the specific scope the user has selected.
Step 2: Time Series Construction
The historical daily data is assembled into a regular daily time series — one value per calendar day. Any days with no recorded usage are filled with zero, ensuring a continuous, evenly-spaced series with no gaps. This regularity is required for the decomposition algorithm to work correctly.
Step 3: Time Series Decomposition
The continuous daily series is decomposed into three additive components using the classical decomposition method:
Observed Value = Trend + Seasonal Component + Residual
| Component | What It Represents | How It's Calculated |
|---|---|---|
| Trend | The baseline level of spending, excluding cyclical fluctuations | Computed as the average of the historical data, representing the central tendency |
| Seasonal | Recurring cyclical patterns (e.g., higher spend on weekdays, lower on weekends) | Detected using a 30-day seasonal period, which captures monthly billing cycles and day-of-week patterns |
| Residual | Random, irregular fluctuations not explained by trend or seasonality | The remainder after removing trend and seasonal components |
The 30-day seasonal period is significant: it means the model looks for patterns that repeat on a roughly monthly cycle. This captures effects like monthly billing cycles, end-of-month processing spikes, and weekday/weekend usage differences.
Step 4: Forecast Projection
The decomposed components are projected forward to generate predicted values for each future day in the forecast horizon:
- The trend (average level) is carried forward as a constant baseline.
- The seasonal pattern detected from the historical data is repeated into the future.
- The residual (random noise) is not projected — it represents unpredictable variation.
The result is a daily forecast that combines the baseline spending level with the expected seasonal pattern for each future day.
Step 5: Forecast Horizon
The forecast horizon — how far into the future predictions extend — is calculated dynamically:
- Spend, CO₂e, and kWh: defaults to the end of the current month plus two months (approximately 2–3 months ahead)
- By Service and By Subscription: defaults to one month ahead from today
Users can specify a custom target end date to extend or shorten the horizon.
Step 6: Actual vs. Forecast Separation
For days where actual usage data has already been recorded, the system does not report a forecast. Instead:
- The actual spend is shown for that day.
- The forecast portion is calculated as the difference between the predicted value and the actual value, but only if the prediction exceeds the actual (otherwise zero). This prevents double-counting.
In other words, for past and current days with real data, you see actuals; for future days without data, you see the forecast.
Step 7: Monthly Aggregation
When monthly granularity is requested, daily forecasts are rolled up into monthly totals. The current (partial) month receives special handling:
- Actual spend-to-date for days that have already occurred in the current month
- Plus forecast for the remaining days in the month that haven't happened yet
This gives a blended "month-to-date actual + projected remainder" figure for the current month, and pure forecast for all future months.
Forecast Output Structure
The forecast results include:
- Daily or monthly forecasts — individual data points for each period
- Monthly totals — spend and forecast aggregated by month within each year
- Yearly totals — spend and forecast aggregated by year
Each forecast record contains:
| Field | Description |
|---|---|
| Usage Date | The date the forecast applies to |
| Spend (Actual) | Actual recorded spend for that date (zero for future dates) |
| Forecast | The forecast amount for that date (zero for past dates with actuals) |
| Total Forecast | The sum of actual + forecast, representing the complete projected figure |
Assumptions and Limitations
What the Model Assumes
- Recent patterns persist: The forecast assumes that the spending patterns observed in the last 70 days will continue into the future. It does not predict structural changes.
- Additive seasonality: Seasonal effects are assumed to be constant in magnitude (additive), not proportional to the overall level (multiplicative).
- Average trend: The trend is modelled as an average, not as a growth or decline trajectory. The forecast will not extrapolate upward or downward trends — it projects the current average level forward with seasonal adjustments.
What the Model Does Not Account For
- Planned infrastructure changes — scaling up/down, new subscriptions, decommissioning resources
- Price changes — cloud provider price revisions, reserved instance expirations, savings plan renewals
- One-off events — anomalies, migration spikes, or temporary workloads that won't recur
- Long-term trends — because the trend is an average (not a regression), sustained growth or decline in spend is not extrapolated
- External factors — market conditions, organisational changes, or contract renegotiations
Accuracy Considerations
- More history improves accuracy: The 70-day lookback provides a reasonable seasonal signal, but tenants with highly variable spend may see less accurate forecasts.
- Stable environments forecast best: Tenants with consistent usage patterns and minimal one-off events will see the most reliable forecasts.
- Early in the month: Forecasts for the current month are a blend of actuals and predictions; accuracy improves as the month progresses and more actual data becomes available.
- New tenants: Tenants with less than 70 days of history will have forecasts based on whatever data is available, which may be less reliable.
Practical Guidance
When to Trust the Forecast
- For budget planning and trend monitoring over a 1–3 month horizon
- When spend patterns are relatively stable and recurring
- As a planning indicator, not a precise prediction
When to Apply Judgement
- If you know of upcoming changes (new workloads, contract renewals, price changes), adjust expectations accordingly — the forecast won't reflect these
- For long-range planning beyond 3 months, treat forecasts as directional only
- If recent spend includes one-off spikes (e.g., a migration), the forecast may be temporarily elevated
Interpreting the Current Month
The current month's figure is a work-in-progress estimate: it combines what has actually been spent so far with a forecast for the rest of the month. As each day passes and actual data replaces forecast, the figure becomes more certain. By month-end, the figure should closely match the actual total.