Lead Time
Calendar weeks the action takes, including the waiting, from the person who would run it.
FREE TEMPLATE
Infrastructure Capacity Planning Template
Five documents and three sheets, including a trigger register where every threshold is derived from how long its own action takes.
Free download · No account needed
Scaling Trigger Register, one row
The resource, and the single action that adds capacity to it
Owner: one person · Executes with: the teams whose time it needs · Last reviewed
Margin
Half again where nobody has ever run it. A quarter where somebody has, and recorded what it took.
Runway Lead time times one plus the margin. This is the room the trigger has to leave, and it is the only reason the threshold is the number it is.
Derived Level The utilisation that still leaves exactly that runway at the current growth rate. Calculated, never chosen, and it moves when growth does.
Trigger Kind Rate where the driver is a curve. Date where it is an event, fired at the event minus this row's runway, because a threshold cannot see a date coming.
Fires At
A percentage of the ceiling, or a calendar date. One or the other, and the arithmetic behind it is shown so nobody re-derives it under pressure.
Status
Watching, scheduled, or late by a stated number of weeks. Late is arithmetic rather than judgement: the start date has passed.
A capacity threshold is normally chosen. Eighty percent, or whatever the last plan used, applied to everything in the estate. That number says how full a resource is and nothing at all about whether anybody can still act on it. Every threshold in this pack is derived instead, from the calendar time its own action takes. Raising a provider quota is not a setting you change: AWS says plainly that larger increase requests take time to review, process, approve, and deploy. The threshold is whatever falls out of that.
Thurlby runs fleet telematics. Eighty-four thousand vehicles, 4,200 messages a second, growing 3.2 percent a month, five resources with real ceilings. Derived from their own actions the triggers land at 96.8, 88.7, 98.2, 92.1 and 93.7 percent, every one of them above the eighty percent the old plan applied to all five. The single alert that had fired, ingest partitions at 83.3 percent, sits behind a three-week action with nine and a half weeks of slack. The plan was pointing the platform team at the least urgent thing it owned.
Then a customer signs. Rowanbank Logistics connects twenty-six thousand vehicles on one morning fourteen weeks out, and four of the five resources cross their threshold and their ceiling in the same instant, which leaves every lead time at zero. Those four stop being thresholds and become dates. The shard split behind the write path needed to start two and a half weeks ago. Ceilings come from a load test, and whether anything would page you comes from a coverage review.
What is in the pack
01
Scaling Trigger Register
One row per action, with the lead time, the margin, the runway those two produce, the derived level, and the one person who starts it.
02
Headroom Analysis
One row per resource with a real ceiling, marked measured or configured, and where the resource lands the hour a dated event arrives.
03
Utilisation Trend by Service
Monthly history against the driver rather than the percentage, which is what lets a growth rate survive a ceiling moving underneath it.
04
Capacity Plan
The plan itself, opening with whatever is already late, then growth split into the continuous part and the dated part.
05
Scaling Approach
What actually adds capacity to each resource: the steps, what breaks while it runs, what it does to the bill, and whether it reverses.
06
Trigger Note
One page to one decision-maker the day a trigger fires, leading with the date the action has to start rather than with a percentage.
07
How a Trigger Is Derived
The arithmetic written out once, including why an action nobody has rehearsed carries half its lead time again as margin.
08
Trigger Alert
A weekday check reporting the slack between the runway left and the runway the action needs, and staying silent when nothing fired.
How it works
- 1
Open it in River, or download it
Edit with AI installs the pack as a private Space with the agent primed to fill it in. Download gives you the documents as Word files and the sheets as CSV, with no account.
- 2
Send the history and the calendar
Utilisation exports, quota and contract limits, the growth forecast, and anything with a go-live date on it. The signed contracts matter more here than the dashboards do.
- 3
Get a lead time on every action
River asks what somebody actually does to add capacity to each resource, how long it takes including the waiting, and whether anyone has ever done it. Then it derives the level.
- 4
Separate the curves from the dates
Anything that moves with a dated event gets a date trigger fired at the event minus its own runway, because a threshold on a metric cannot see a step arriving on a Monday.
Frequently asked questions
Is this template free?
Yes. The zip is Word documents and CSV sheets, and it needs no account and no card. Edit with AI is the optional half: the agent reads the utilisation history and the contracts you already have, finds the ceilings, and derives each level. The rest of the template library works the same way.
What format are the downloaded files?
The documents come as .docx and the sheets as .csv, so nothing needs converting. Word, Pages, Google Docs, Excel, Numbers and Sheets open them directly. The three sheets arrive carrying the worked telematics example, so you can see a filled register before you replace it with your own.
What does Edit with AI actually do?
It reads what you send and writes one row per resource with a real ceiling, one row per action with a lead time, and a derived level for each. Then it checks every dated event against every resource and reports which triggers should have started already.
Why not just alert at eighty percent?
Because eighty percent is a statement about how full something is. At Thurlby all five derived levels came out above it, so the blanket threshold was early on every resource. The one alert it did fire pointed at the action with the most slack rather than at the one already late.
Our ceilings are the configured limits. Is that enough?
The register records which they are, because they are different claims. Google's SRE book is direct about it: unless you test in a realistic environment, it is very hard to predict exactly which resource will be exhausted and how. A load test is what turns a configured number into a measured one.
We replan every quarter. Why add triggers?
Because a quarterly plan assumes nothing lands between quarters. Google's SRE book describes the traditional cycle as brittle enough that a rise in customer adoption can mean re-creating the plan from scratch. A dated trigger survives that, since it is counted from the contract rather than from the review calendar.
Does this tell us what the scaling will cost?
It carries the one-off and the change to the run rate for each action, phased against the dates. Where the bill itself is the question rather than the capacity, that is a cloud cost analysis, and what to do when a peak arrives anyway belongs in a runbook. What an action does to the estate when somebody runs it is a blast radius map.