The Monthly Capacity Review

Before deciding what to do, we need operations to confirm whether the observed workload still resembles the one tested, Product to explain what comes next, the batch owner to tell us what the delay has meant for its customer, and the latest supply estimate. Some of that will already have surfaced in the monthly meetings with the largest consumers that the Introduction described. The review is where those answers meet the decision they all affect.

How to read this chapter

This chapter is about the monthly review itself, the meeting where cost, capacity, and capability are reviewed together: what goes into it, how it runs, what it records, and what brings a decision back early.

1. Keep the original forecast — what a later revision must not do to it.
2. Review the decision, not only the prediction — forecast error is not the whole assessment; demand, completed work, ready supply and cost are followed together.
3. Prepare the decision before preparing the slides — one pack for everyone, the agenda, and a short snapshot for senior management.
4. A record for this month’s choice — options, arithmetic, and authority.
5. Don’t wait for the next review — triggers agreed in advance.
6. When the meeting cannot agree — arguments worth having, and escalating while every option still exists.
7. Reward the correction — making early revisions worth sending.
8. The capacity team’s own record — the measures we apply to ourselves.
9. Run the example, then change it — the companion as a rehearsal.
10. Start with what is already due — the first review.

The lesson to carry: the review is where the book’s numbers become decisions, and its output is a record someone can challenge next month.

Keep the original forecast

Chapter 14’s table gives the errors, actual minus forecast: +2,800 requests per second for the baseline and +800 for the adjusted forecast. Demand intelligence improved this particular forecast by that measure. I want to keep that result without claiming that we predicted the peak or that the smaller error proves the service was safe.

In the companion’s counter-scenario, a delayed rollout peaks at 10,200, and the adjusted forecast becomes the worse one, missing by −1,800 against the baseline’s +200 (Volume I, Chapter 4 and Volume II, Chapter 14). In the review, I would ask when the delay became known and whether there was still time to change the commitment.

One month’s comparison is an anecdote, so the review keeps each forecast’s versions and errors from month to month until bias at the horizons where we decide becomes visible. Without that history, a relationship-based planning practice can become very good at remembering the occasions when a conversation helped and surprisingly incurious about the occasions when it did not.

Review the decision, not only the prediction

For the portfolio, I would follow the outcome through four connected questions. What demand arrived, and how did it differ from the estimate? What work did the service complete at the required quality, including the demand it rejected or left queued? What supply was ready, in which configuration and for which dates? Finally, what did the arrangement cost or defer, and which obligations remain exposed?

The last question is where reports most often lose their distinctions, and Volume I, Chapter 13’s categories keep them: the transfer’s $9,600 is shifted cost and released capacity, not a saving, and the new group’s quoted $640 a day is a potential new charge whose cash effect Finance has to establish. I know this can sound fussy when everybody wants to talk about the successful launch. Three months later, when somebody asks where the saving went or why batch missed its deadline, we will wish the report had kept them.

Prepare the decision before preparing the slides

I have seen cost reviews acquire a preliminary meeting to get the story ready. Some preparation is useful: check calculations, find missing context, and let people understand what they will be asked to decide. There is also a version in which the inconvenient parts disappear until the material supports the desired conclusion. On a calendar the two look the same. The remedy I have argued for is one regular report, in a format that does not change from month to month, which no executive needs to approve before it is shown.¹

For the capacity review, that pack reaches every participant at the same time, a few working days ahead, so that whoever owns a number can correct it before defending it in front of executives. A disagreement that cannot be settled in time stays in the pack as a disagreement.

The agenda

In the room are the people whose authority this month’s decisions need and the owners of any exception; everyone else gets the pack. The capacity lead prepares the pack and runs the meeting, but the decisions belong to the owners named in each record. Most services never reach the agenda, which spares a large portfolio the meeting in which every owner narrates every row while the rest of the room answers email. At enterprise scale the structure repeats: service reviews, Chapter 21’s market reviews, and a portfolio review that sees only what the others could not decide.

Senior management gets a separate monthly meeting, and it should be very quick. If cost and capacity are running well, we don’t want a lot of meetings with senior management; a lot of them means something is going wrong or needs escalation. What they need each month is a snapshot, so that nothing coming surprises them, with room to bring a problem when there is one.

Carried items include the longest-running requests. In the monthly meetings I kept repeating one: tell me what the ultimate deployment plan for this system looks like, years ahead, because contracts with providers and agreements with suppliers often run for several years. Chapter 23 explains why engineering teams resist that question. Those meetings were also where the capacity and cost teams communicated with projects formally.

An AI program may warrant a long discussion, but so may an expiring commitment or an old environment that a migration still has not released. I would give the time to the consequence and the deadline, even when another technology makes for a more fashionable agenda.

A record for this month’s choice

Engineers who keep architecture decision records in the form Michael Nygard proposed will recognize the shape,² with two additions for capacity: the date after which the record stops being true, and the people whose commitments it changes. This one, from the constructed portfolio, follows the companion’s launch decision, D-001.

Observation. The first-stage peak reached 12,800 requests per second, against a baseline of 10,000 and a staged estimate of 12,000. Operations has not yet confirmed that the request mix stayed within the tested basis of 250 per worker; every capacity figure below depends on that check.

Remaining room. Four groups of 18 support (72 − 18) × 250 = 13,500 after losing a group: 700 above the observed peak, and less than the 800 by which the adjusted forecast just missed. Each of the 54 surviving workers would carry 12,800 ÷ 54 ≈ 237 requests per second, about 95 percent of the tested rate.

Deadline. The transfer ends at the start of day 32; the new group is estimated to be qualified on day 42. The next review meets after day 32, so this one settles the ten-day gap or sets an earlier date for settling it, with time left for the batch owner to plan.

Options for days 32 to 42.

• Extend the transfer to day 42. Attribution rises from $9,600 to $12,800 (Chapter 18), with no additional enterprise cash; batch waits ten more days. Needs the batch owner’s agreement and a catch-up plan.
• Return the workers on day 32. Degraded capacity falls to (64 − 16) × 250 = 12,000, so a group failure during a peak like the last one would leave us 800 short. Needs the responsible executive to accept that exposure for up to ten days.
• Keep first-stage demand below 12,000 until day 42. Needs Product and the business owner to narrow the audience or defer the heaviest operations, which current users will notice.
• Qualify another source before day 32. Needs the supply owner, Finance, and evidence that it can be ready in time.

If supply slips to day 70, the bridge becomes 68 days and $21,760: a different agreement, not an extension of this one.

Recommendation. Extend to day 42 if the batch owner’s catch-up plan holds. If it does not, ask Product whether the first stage can be narrowed, and take whatever exposure remains to the responsible executive with the 800 stated. Either way, hold the next stage until the new group is qualified. Product’s July 8 revision puts the full rollout at 10,000 + 4,500 = 14,500, which is 1,000 above 13,500 and would leave 1,500, rather than the planned 2,000, under the new group’s 16,000.

Authority and status. The batch owner decides the extension, Product and the business owner decide scope, the responsible executive decides whether to accept the exposure, and Finance owns the spending, including the new group’s $640 a day. The record stays proposed until they decide, and it keeps any refusal or condition; the capacity lead does not mark the plan agreed merely because an option has been calculated.

Reopen if a daily peak exceeds 12,800, the supply date moves past day 42, operations finds the request mix outside the tested basis, the batch catch-up plan fails, or Product wants the next stage before the new group is qualified.

Don’t wait for the next review

A monthly cadence suits decisions with lead times of weeks to months, like the six-week supply estimate here. It is also the slowest route a decision can take, and this month’s transfer ends before the next review meets. Much of the review’s value lies in agreeing ahead of time what brings a decision back between meetings.

I have argued for setting escalation thresholds before the fiscal year begins rather than negotiating them while a team is over budget,³ and the FinOps Foundation’s Forecasting capability asks for variance thresholds and notification when one is crossed.⁴ For capacity, I would express the threshold in the unit of the decision and start from our own recent misses: when the room left under the stated failure is smaller than the latest forecast error at the decision’s horizon, as 700 is smaller than 800 here, the decision comes back now.

A trigger needs something observable, someone watching for it, and someone who must hear within a working day. Each condition in the record’s reopen list has an owner who calls the capacity lead when it moves, and the capacity lead convenes only the people whose authority the changed decision needs, reporting the outcome at the next review. A trigger that fires every week is measuring noise; one that has never fired should be tested to see whether it can.

When the meeting cannot agree

Some reviews were routine: check a box, confirm the plan was where it was. The best ones had a real argument, because that is how you establish what people actually need and how to support them. It’s an uncommon thing to say, but I love it when people have fights about things. The other reviews I valued were the ones where a team came with ideas, not just requirements.

An argument becomes a problem when the meeting cannot settle it while every option still exists. Volume I, Chapter 3 described what to do then: take the alternatives, their consequences, and their expiry dates to someone who can change the obligations together, with the other parties rather than about them, or to the standing committee of qualified technical people when the dispute needs a technical ruling. If the batch owner cannot give ten more days, Product will not narrow the first stage, and the business owner will not accept the exposure, the one-page account goes this week to whoever can change those obligations together. It states the 800 requests per second we would be short under the modeled failure from day 32 to day 42 and the date after which waiting removes an option, so the impasse does not come back next month as a carried item with one option fewer.

There is a difficult moment when the meeting wants certainty that the evidence cannot supply. I would explain what we can support, what would make another option feasible, and whose commitment has to change if those conditions cannot be achieved. We can help without converting a forecast into a guarantee or treating the need for an answer as evidence that a resource is available.

Reward the correction

People notice what happens after someone brings unwelcome information, and sometimes the truth is not rewarded: whoever brings the bad news gets blamed for it. If an early correction earns blame while a late surprise produces an emergency budget, another reminder about transparency will not repair the incentive. There is a truth-or-consequences game in cloud capacity: if people don’t share an honest assessment of capacity, limits, and cost, there comes a moment when the model completely breaks down and nobody has capacity, because nobody was telling the truth.

Reliability engineers worked through this for incidents. The SRE book’s chapter on postmortem culture warns that where finger-pointing prevails, people stop bringing issues to light, and it recommends visibly rewarding people who do the right thing.⁵ Allspaw’s account of a just culture keeps that from becoming permissiveness: the people involved remain responsible for helping make the system safer.⁶ A forecast revision is the capacity version of raising a problem early, so the review should:

• keep the date each revision arrived beside the deadline it preceded, so that Product’s revision, which came two days after the peak and well before the next stage, is credited with its lead time even though the news makes the plan harder;
• judge owners on whether they revised when they learned something, and said why, rather than on the size of the miss;
• let a downward revision or cancellation release what it can without automatically cutting the team’s budget (Chapters 17 and 20);
• ask when we first knew before asking who was wrong.

One outcome of the monthly meetings is an honest assessment of where each project stands. Sometimes people get congratulated, especially when the news is good about them. When the assessment is a delay or an overspend, be careful how you communicate it to management. You don’t hire a skywriter to write over headquarters that something is late; you find ways to get the message back to management without necessarily getting people fired. Chapter 17 covers protecting the person who told you.

Accountability still matters for neglected work and avoidable mistakes, but it should follow behavior people can influence: examining assumptions, reporting changes, preserving evidence, and acting on constraints they already know about. Otherwise we teach people to defend the last answer long after they have reason to doubt it. If the updates coming back become shorter and more defensive, the review has become a place people would prefer to avoid, and another set of mandatory fields will make the report look fuller while we learn less.

The capacity team’s own record

Chapter 17 argued that the vested interests worth worrying about include ours. The capacity team puts more numbers into this meeting than anyone else, which is why our corrections lead the agenda. If our forecast was too high, we say so. If our savings report counted the transfer as a reduction, we restate it. Where our process discouraged a cancellation or turned a tentative estimate into a promise, we change the process rather than explain why the customer should have understood it better.

I would want the team judged, by whoever it reports to, on what it controls:

• forecast bias at the horizons where decisions are made, month over month;
• the share of decisions that reached the review before their action deadline, the most direct test I know of whether the review helps anyone;
• the time from a trigger firing to a decision;
• questions carried for several reviews without an answer;
• corrections to our own published numbers, where a long run of zero deserves a look before anyone celebrates it.

Run the example, then change it

Volume I, Chapter 4 introduced the companion; here it serves as a rehearsal. From the directory that contains examples/ in your copy of the companion repository, run:

python3 examples/capacity_portfolio/run.py

Then copy the examples directory and change one condition in the copy’s fixtures/portfolio.json; the program reads the fixtures beside the script you run. Moving new_supply_ready_days from 42 to 56 stretches the gap to 24 days and the bridge to 54 days, attributing $17,280. Setting transfer_per_group to zeros leaves the observed 12,800 peak 800 short under the modeled failure. Lowering tested_requests_per_worker_second to 230 cuts even the temporary arrangement to 12,420, below the observed peak. Several companion tests will then fail because they assert the book’s canonical values; which ones fail is worth reading too. Read each new report as someone who has to act on it: which commitment no longer works, who needs to be involved, and what would you want to learn before agreeing to the proposed response?

The example is deliberately small enough to inspect, and it knows nothing about your contracts or customer obligations. A passing calculation establishes the result under the supplied assumptions; it does not confirm that a provider has accepted a reservation, that a recovery deployment works, or that new supply will arrive by the modeled date. Those need evidence from the systems and people responsible for them.

Start with what is already due

If I were starting this review, I would not begin with a dashboard for the whole fleet: like a mandate to standardize the company, it would give us a great deal to administer before we had learned whether our method helped anyone. I would list the decisions already on the calendar within the longest supply lead time we depend on: commitments expiring, borrowed capacity due back, supply estimates awaiting confirmation, launches with dates. The first pack can cover only those. Each later month adds what those decisions turned out to need and drops what nobody used.

The relationships need to remain close enough that a change in the business can reach the plan before it announces itself through the machines. We will still have forecasts that disagree and measurements that remain incomplete when a choice is due. Sometimes we will learn too late to preserve the option we wanted. What I want from the review is an honest account of how we reached that point and a better chance of keeping a useful choice open next time.

I would start with the decisions already due and the people who own them. Then I would check when the borrowed capacity has to go back.

Notes and sources

1. Tim O’Brien, “Stop Turning FinOps Into Marketing”, Medium, September 27, 2025; the URL preserves the essay’s earlier title, “FinOps Anti-pattern: The ‘Pre-read’ Meeting.” Adapts the essay’s recurring observation of one-sided pre-read meetings and its recommendation of a single, regular report. Advance factual review is distinguished from tailoring evidence to a conclusion; no particular meeting or executive is described.↩︎

2. Michael Nygard, “Documenting Architecture Decisions”, Cognitect blog, November 15, 2011, accessed October 3, 2026. Proposes short records with title, context, decision, status, and consequences, keeping reversed decisions marked as superseded. The expiry date and named commitments are this chapter’s adaptation.↩︎

3. Tim O’Brien, “Stop Turning FinOps Into Marketing”, Medium, September 27, 2025, section “Agree on Conditions for Success.” The essay concerns cloud-spend reviews; applying advance thresholds to capacity triggers is this chapter’s extension.↩︎

4. FinOps Foundation, “Forecasting”, FinOps Framework capability, accessed October 3, 2026. Lists variance thresholds among the forecast parameters to define, describes a regular review of thresholds and trends with stakeholder teams, and counts notification when a variance threshold is exceeded among its measures of success. Its “Shifting Left” guidance likewise treats a pre-decision estimate as a forecast with its own accuracy record. Its accuracy rate is (forecast − actual) ÷ forecast, the opposite sign to this book’s actual-minus-forecast error. The capability addresses spend and usage forecasts; a threshold expressed as room under a failure condition is the author’s proposal.↩︎

5. Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds., Site Reliability Engineering (O’Reilly, 2016), Chapter 15, “Postmortem Culture: Learning from Failure”, by John Lunney and Sue Lueder, accessed October 3, 2026. Describes blameless postmortems, warns that finger-pointing keeps people from bringing issues to light, and recommends visibly rewarding people for doing the right thing. Written about production incidents; applying it to forecast revisions is the author’s extension.↩︎

6. John Allspaw, “Blameless PostMortems and a Just Culture”, Etsy Code as Craft, May 22, 2012. Argues for examining the circumstances and decisions behind a failure rather than punishing the people involved, who remain responsible for helping make the system safer. Written about operational incidents, not forecasts.↩︎