Three forecast methods and when to use each
Run-rate: today's MTD divided by elapsed days, times days-in-month. Cheap, fine for steady workloads. Seasonality-adjusted: weight weekdays vs weekends or business hours vs nights using the prior month's pattern. Ramp-aware: layer step-changes for known release dates, customer onboardings, or feature flag rollouts.
Why simple run-rate fails after a release
A run-rate forecast assumes today's daily spend rate is representative. The moment a release ships, that assumption breaks: the forecast under- or over-shoots until the new rate becomes the average. Switching to seasonality- or ramp-aware forecasting after a known step-change shortens the recovery window.
Adjusting for weekday/weekend seasonality
Most SaaS bills are 60-80% workload-driven, which means weekend spend is meaningfully lower than weekday. A naive run-rate computed on a Monday over-projects. Multiply each remaining day by its prior-month-weighted scalar instead of by 1.
Handling step changes
When a new customer onboards mid-month, the forecast should account for their projected rate of new spend from cutover, not their historical zero. Attach a 'step-change' annotation to the forecast that the alert message references, so the person paged knows why the number jumped.
Building a daily 'today-vs-projected' panel
Two lines on one chart: actual MTD and projected month-end. When projected exceeds last month by more than a chosen percent, fire the slope-based alert. Engineers tend to trust this panel because they can see the forecast slope move as their changes ship.
Forecast-based vs threshold-based alerts
Threshold alerts fire when MTD crosses a number — useful for catching blow-ups. Forecast alerts fire when the projected close moves outside an expected band — useful for catching drift. Both belong in a mature setup; pick one if you can only have one and bias to forecast for engineering-led teams.
Worked example: AWS + DO project, day 12 of 30
MTD = $2,100. Simple run-rate: $5,250 close. Seasonality-adjusted (more weekend days remaining): $4,940. Ramp-aware (new customer onboarded day 8 at +$30/day): $5,090. Picking the seasonality+ramp adjusted figure gives the team a defensible projection for the close.
Who tovin.io is for
Frequently asked
How accurate should the forecast be?
Within 5–10% by day 10 is realistic for steady workloads. Tighter than that needs ramp metadata about known step changes.
Is a linear projection enough?
Only for steady workloads. SaaS with weekly cycles needs seasonality adjustment to stay credible.
What should fire the alert — threshold or forecast slope?
Both. Thresholds catch blow-ups; slope catches drift. If you have to pick one, pick slope for engineering-led teams.