Use this when you have visibility into cost but no regular process for turning that visibility into decisions.
The fast answer: run a 30-minute weekly review with one engineering owner and one product owner. Cover pacing, top deltas, anomalies, and one to three clear actions. Log decisions and owners.
Why weekly specifically — not daily or monthly
The cadence matters as much as the content.
Daily is too frequent for decisions. Daily monitoring is for detection — catching anomalies before they compound. But decisions about whether to optimize a workflow, revise a forecast, or change a model require context that accumulates over days, not hours. A daily meeting about cost becomes noise quickly.
Monthly is too infrequent to act. By the time you run a monthly cost review, the problems you are discussing happened three weeks ago. The engineer who made the relevant change has moved on to other things. The context is stale, and even if you identify something to fix, the fix will not ship until the following billing cycle.
Weekly is the right interval for closing the loop. It is fast enough that anomalies from the past seven days are still fresh. It is slow enough that there is something meaningful to review — trends, delta comparisons, forecast movement, and accumulated action follow-ups. Most importantly, it is the cadence at which most engineering teams already plan and prioritize work, so cost actions can be slotted into sprints immediately rather than waiting for a separate process.
A team that runs a consistent 30-minute weekly review will outperform a team with sophisticated tooling but no operating rhythm. The tooling surfaces data. The rhythm turns data into decisions.
Who joins and what they own
Keep attendance small and intentional. Every additional person who does not own anything in the review adds time without adding decisions.
| Role | Responsibility |
|---|---|
| Engineering owner | Explain deltas, own investigation and optimization follow-up |
| Product owner | Connect cost changes to launches, features, and user growth |
Optionally add finance or ops if spend is already material and forecast changes need immediate context. Do not add people "for visibility" — they should read the shared log instead.
This is an operating review, not a status meeting. The distinction matters: a status meeting informs attendees. An operating review produces decisions.
Weekly review agenda
Use this 30-minute format. If it regularly runs longer, the data is unclear or the agenda scope is drifting.
1. Pacing (5 min)
What to cover:
- Total spend last 7 days vs prior 7 days
- Month-to-date vs plan
- Forecast for month-end if current pace continues
Why this block exists: Pacing is the one number that tells you whether everything else is fine or in trouble. If forecast is tracking to plan, the rest of the review is mostly confirmation. If forecast is running 15 percent above plan, every other conversation in the review gets colored by that fact. Starting here sets the frame for the rest of the discussion.
What a good result looks like: Forecast is within 10 percent of plan. Week-over-week spend is flat or growing in line with the product growth rate you expect.
What needs investigation: Forecast is more than 10 percent above plan. Week-over-week spend jumped more than 20 percent without a known reason. This becomes the primary discussion for the rest of the meeting.
2. Top deltas (10 min)
What to cover:
- Which provider increased or decreased the most?
- Which model or service?
- Which feature or workflow if you have that data?
- Was the change expected?
Why this block exists: Total spend numbers tell you something moved. Deltas tell you what and by how much. This block is where the engineering owner explains the specific drivers rather than the group speculating. The goal is not to fix anything in this block — it is to understand what happened and decide whether it needs follow-up.
What a good result looks like: Every delta has a clear explanation. "OpenAI spend was up 18 percent because we launched the email summarization feature on Wednesday and it is running at expected volume." That is a complete answer. The review moves on.
What needs investigation: A delta cannot be explained. "We are not sure why Bedrock spend doubled this week." That is an action item: someone owns finding the answer before the next review.
A useful discipline here is to require explanation, not just observation. The engineering owner's job is not to report that OpenAI went up — the dashboard already shows that. Their job is to explain why. If they cannot explain it, that is the most important finding of the review.
3. Anomalies and incidents (5 min)
What to cover:
- Any material alerts since last review?
- Any spikes that were investigated and resolved?
- Any rollbacks or config changes that affected cost?
Why this block exists: This is the explicit checkpoint for anything that bypassed the normal review cadence. If an alert fired on Wednesday and someone investigated and fixed it, this is where the resolution gets documented and closed. If an alert fired and was not fully investigated, this is where it becomes an explicit action item rather than sitting in an alert channel that nobody is actively watching.
What a good result looks like: All alerts from the past week are either closed with a known cause and resolution, or actively owned with a due date.
What needs investigation: An alert fired more than twice for the same cause. That usually means the threshold is miscalibrated or the underlying issue was not fully resolved.
4. Actions and owners (10 min)
End with one to three actions. Each action has an owner, a clear deliverable, and a due date. No more than three — a list of eight "actions" is a list of good intentions.
Why this block exists: Reviews without actions are updates. The entire point of the operating rhythm is to turn cost visibility into decisions. This block is where that happens explicitly rather than implicitly.
Examples of well-formed actions:
- Investigate Bedrock inference increase — [Name], by Friday
- Reduce prompt length in summarization workflow — [Name], this sprint
- Check whether fallback routing to premium model is over-firing — [Name], by next review
- Revise month-end forecast to reflect new summarization volume — [Name], share with CFO by Tuesday
Examples of poorly formed actions:
- "Look into the OpenAI thing" — No owner, no definition of done
- "Maybe optimize something" — Not actionable
- "Let's monitor and see" — This is not an action
If there are no actions, record that all changes were expected and the review is complete. That is also a valid outcome. The key is that the decision is explicit, not that something always needs to change.
A worked example: the review where inference jumped 22 percent
Here is what a specific weekly review looks like when something needs attention.
Context: A team of 8 engineers is building an AI-powered customer support product. They use OpenAI for inference, AWS for compute and storage, and a managed vector database for retrieval.
Pacing (5 min):
- Last 7 days total: $4,820 vs prior 7 days: $3,950 — up $870, +22 percent
- Month-to-date: $14,200 vs plan: $12,000 — running 18 percent above plan
- Month-end forecast at current pace: $18,800 vs budget: $16,000
The engineering owner flags this immediately. The forecast gap means the conversation from here is about understanding and addressing the $2,800 overpace, not just reviewing what happened.
Top deltas (10 min):
- OpenAI inference: up $650, +28 percent week-over-week
- AWS compute: up $180, +12 percent week-over-week
- Storage and networking: flat
The engineering owner explains: OpenAI is up because the new conversation summarization feature launched on Monday. It is running on every support ticket that goes past 10 messages, which turns out to be about 40 percent of all tickets. The compute increase is background workers processing those summaries in batches.
The product owner adds: the feature was expected to launch, but the 40 percent trigger rate is higher than they assumed in the budget model. They assumed 25 percent.
Anomalies and incidents (5 min):
One anomaly alert fired on Tuesday when OpenAI spend spiked. The engineering owner investigated and confirmed it was the summarization feature going live. Alert closed.
Actions and owners (10 min):
- Reduce summarization trigger threshold from 10 messages to 15 — [Engineering owner], this sprint, expected to reduce volume by 20 percent
- Revise month-end forecast to reflect actual trigger rate — [Product owner], by Wednesday
- Add cost-per-ticket tracking to the review dashboard — [Engineering owner], next sprint
Total review time: 27 minutes. The team leaves knowing what happened, who is fixing it, and when.
What decisions get logged
A useful review produces a written record, not just a verbal conversation. The log does not need to be long — a few lines per review is enough. What matters is that someone can read it and understand what the team decided.
Log in one of these categories:
- Leave as-is — Change is expected and accepted at the current level
- Investigate — Owner + due date
- Optimize — Owner + specific tactic + due date
- Revise forecast — Owner + new number + communication plan
- Escalate — Who, why, by when
The log doubles as the starting point for the next review. The engineering owner should scan it before every meeting to confirm that previous actions were completed.
Escalation triggers
Weekly review handles most situations. Escalate beyond the review process when:
- Forecast is 20 percent or more above plan with no clear fix — this needs a leadership conversation about whether to cut, reprioritize, or update the plan
- A spike is unexplained after one full investigation cycle — something structural may have changed that the team has not found yet
- A provider or model change affects a material customer or feature in a way that has customer-visible consequences
- Spend growth does not match product or user growth and margin is at risk — this is no longer a cost operations question, it is a product economics question
When you escalate, bring the forecast number, the explanation of what changed, and the options being considered. Do not escalate to ask someone else to decide — escalate to communicate clearly and get a fast decision.
Monthly follow-up rhythm
The weekly review handles pace and action. Add a monthly layer for decisions that require more data:
- Budget vs actual reconciliation — confirm the month closed as expected
- Provider and model mix changes — are cost proportions shifting in ways that affect forecast assumptions?
- Architecture or optimization backlog prioritization — which improvements should make it into the next sprint cycle?
- Forecast accuracy review — how accurate was last month's forecast? What would improve it?
The monthly review should take about an hour. It informs the budget model for the following month and surfaces improvements that are too large to address in a weekly sprint cycle.
What goes wrong with reviews
These are the patterns that turn a useful process into one that people stop showing up to:
No actions — A review that ends without any clear next steps is a status update. People stop coming because nothing changes as a result. End every review with at least one explicit decision, even if that decision is "no action needed this week."
No owners — An action assigned to the team is an action assigned to nobody. Every action needs one named person who is responsible for completing it before the next review.
Running long — A 30-minute review that regularly takes 60 minutes is a poorly scoped review. If the agenda is clear and the data is visible before the meeting, 30 minutes is enough for almost any weekly review. When reviews run long, it usually means someone is presenting data rather than explaining decisions.
Reviewing data in the meeting — The engineering owner should have already looked at the dashboard before the review starts. The meeting is not for looking at numbers together for the first time — it is for explaining what the numbers mean and deciding what to do.
Skipping escalation thresholds — Teams that treat every overpace as "manageable" without escalation often find themselves explaining a large miss to leadership at month-end rather than a small correction opportunity in week two. The escalation triggers above exist to prevent that.
Copyable runbook
Use this structure each week:
Weekly AI FinOps Review
- Date: [YYYY-MM-DD]
- Period: Last 7 days
- Attendees: [names]
- Total spend: $[X] vs prior week [+/-%]
- Forecast for month: $[X] vs plan $[Y]
- Top deltas: [provider / model / feature, reason]
- Anomalies: [none / list with status]
- Actions:
- [Action] — [Owner] — [Due date]
- Next review: [date]
How StackSpend helps
StackSpend gives the review a shared surface:
- yesterday vs forecast
- top drivers by provider, model, service, category
- anomaly follow-up with drill-down
- one view instead of multiple provider dashboards
See cloud + AI cost monitoring for the workflow.