Someone left a test cluster running on the 3rd. It is now the 28th, finance has just sent the month-end report, and the question “why is this 30 percent over budget?” lands on an engineer who last touched that cluster three weeks ago. A review calendar is mostly an answer to one question: how long are you willing to pay for a mistake before you notice it?
There is no single right interval
Nobody publishes one number, and the FinOps Foundation does not pretend otherwise. Its forecasting capability asks you to “establish requirements for when forecasting is due and how frequently forecast updates are needed”, which is a polite way of saying it depends on you. What the primary sources do agree on is the shape: a fast, automated layer underneath a slower, human one.
Daily: let tools watch, not people
The daily layer is alerts. The FinOps Foundation’s anomaly management capability marks a low-maturity team as one “reacting to anomaly activity more than a week after it occurs”. It points the other way for mature teams: unexpected spending “automatically routed to responsible teams”, with thresholds set differently for different roles.
On AWS, two features cover this. AWS Cost Anomaly Detection runs “approximately three times a day” after billing data is processed. Because it uses Cost Explorer data, which “has a delay of up to 24 hours”, it can take up to 24 hours to detect an anomaly after the usage occurs. AWS Budgets updates “up to three times a day”, and can alert on both actual and forecasted spend.
Two details worth knowing. A new anomaly monitor can take 24 hours to start detecting, and a new service needs 10 days of history. And the Foundation warns that sudden increases “can trigger anomaly alerts even when they are anticipated”, so expect some alerts about launches you already knew about.
Nothing here needs a meeting. It needs alerts that reach whoever owns the resource, not an inbox nobody reads.
Weekly: the review that earns its calendar slot
AWS’s Cloud Financial Management team is direct about this: “We recommend operating on a weekly cadence, but removing friction is key.” Its reasoning is about two failure modes. Monthly analysis “may reveal cost trends too late for timely course correction”, while daily cost tracking “may produce limited actionable insights”. A weekly view “filters out short-term fluctuations and noise” and, in AWS’s words, gives a normalized view compared with a daily one.
The format is deliberately light. The central FinOps or finance team holds the meeting “to identify variances requiring an explanation”. It can stay a core team or widen to cost champions and technical contacts. For each account, AWS suggests looking at both variance percentage and annualised impact, and picking what to chase by judgement on those two numbers. A 40 percent jump on a tiny account can wait; a 3 percent jump on your largest one probably cannot.
Its stated benefit is timing: engaging technical teams earlier, “rather than waiting until the compressed timelines of month-end closing”.
Monthly: the closed-books review
Monthly is where finance lives, and it should stay. This is the review against the budget on final numbers: actual versus forecast versus budget, with the variance explained. The FinOps Foundation’s forecasting capability describes reporting “budgets vs actuals vs forecast” and comparing cost trends against an established percentage threshold of variance.
The monthly review explains the past. That is its job, and its limit. By the time it happens the spend is already incurred, which is why it works as a backstop, not as the only control.
Quarterly: commitments and the bigger bets
Once a quarter, step back from variances. This is where reserved capacity, Savings Plans and workload placement belong, because decisions with a one- or three-year term do not benefit from weekly attention. We cover the buying decision in Reserved Instances or Savings Plans: which should you buy?. The quarterly interval is our suggestion, not a Foundation requirement.
How long does a mistake run?
- Monthly review onlyUp to 30 days
- Weekly reviewUp to 7 days
- Daily alertAbout 1 day
The bars are arithmetic, not measurement: the longest you can wait before the next scheduled look is the length of the interval. Alerts are bounded by the billing delay AWS documents, about a day.
The cadence at a glance
| Layer | How often | Who | What it covers |
|---|---|---|---|
| Anomaly alerts and budgets | Continuous, data refreshes several times a day | Resource owners | Spikes, forecast overruns |
| Variance checkpoint | Weekly | Central FinOps, finance, cost champions | Biggest changes by percentage and annualised impact |
| Closed-books review | Monthly | Finance, engineering leads | Actual vs forecast vs budget |
| Strategy review | Quarterly (our suggestion) | Leadership, finance, engineering | Commitments, placement, forecasting method |
Keep it small enough to survive
A cadence only works if people turn up. AWS’s own caveat applies: “removing friction is key”. Give the weekly review a fixed 30-minute slot, a pre-filled list of the largest variances, and one rule: if nobody can explain a change, someone is assigned to find out. The FinOps Framework describes the whole practice as cycling through the Inform, Optimize and Operate phases “rapidly”, looping back continuously, so treat the calendar as a loop, not a ceremony.
Where Auris fits
If you want help setting up this kind of FinOps routine, the Auris FinOps page is where to start. The cadence above needs nothing from us: you can begin this week with the alerts and budgets you already have.
The bottom line
Review costs in layers: alerts daily, a short weekly look at the biggest variances, a monthly close with finance and a quarterly look at commitments. If you can only add one thing to a monthly-only routine, add the weekly checkpoint, because it is the cheapest way to shorten how long a mistake runs.