This free IT capacity planning checklist runs a quarterly review for infrastructure managers, cloud and platform teams and MSPs planning on a client’s behalf. It starts from the services the business relies on, not from a list of servers. It gathers utilisation history and business plans, forecasts four quarters ahead, applies headroom and redundancy targets, and weighs hardware, cloud and reclaim options against lead times and cost. The output is a capacity plan with a named approver’s sign-off and, before budget season, the figures for the annual budget.
ITIL 4 calls this work the capacity and performance management practice: making sure services meet their agreed performance for today’s demand and tomorrow’s, at a cost the business accepts. The weekly disk check is part of it, but only the reactive part. It tells you a volume will fill in 60 days. It cannot tell you that the finance system needs twice the database throughput once the acquisition closes, because that fact lives in a board paper, not in monitoring.
Google’s Site Reliability Engineering book makes the same split. It asks for a forecast of organic demand that reaches further than the time it takes to acquire capacity, plus inorganic demand from launches and business events, plus regular load tests that show how raw resources translate into service capacity. This checklist is built around the first two, and the third belongs in Phase 2’s performance evidence.
Data: current readings against thresholds.
Cadence: weekly or monthly, inside maintenance runs.
Decides: whether to clear space, extend a volume or raise a ticket.
Output: a ticket with an owner.
Data: at least a quarter of history plus the business’s plans.
Cadence: quarterly, with one run feeding the annual budget.
Decides: reclaim, resize, buy, commit or accept the risk.
Output: an approved plan with dates and costs.
Seven phases take a quarterly review from service inventory to approved actions. The hosting model decides which options appear, and a named approver signs off the plan before anything is ordered.
The hosting model recorded here decides which options appear in Phase 5. The budget answer decides whether Phase 6 adds the budget task.
Reclaiming and the recommendation apply to every review. Hardware tasks appear for on-premises and hybrid estates, cloud tasks for cloud and hybrid.
The budget task appears only when this review feeds the annual budget. The named approver signs off, and the checklist halts until they record a decision.
The forecast is the same whichever way capacity is bought. What changes is where the risk sits: on-premises it is running out before the hardware arrives, in the cloud it is paying for capacity nobody uses or hitting a limit nobody checked.
| Question | On-premises | Cloud |
|---|---|---|
| What do you add? | Hosts, memory, disks, rack space, power | Instances, larger service tiers, quota increases |
| How long does it take? | Supplier lead time plus build and burn-in | Minutes to provision; commitments and quota requests need planning |
| Main failure mode | The order lands after the shortfall | Idle spend, or a quota reached at peak |
| Where headroom lives | Spare capacity bought ahead of the forecast | Scaling limits and quotas, with the baseline covered by commitments |
| Main cost lever | Timing of purchases, reuse and decommissioning | Rightsizing, commitments and switching off what is idle |
| Data window | Monitoring history, often a year or more | Provider tools default to short lookbacks: 14 days in AWS Compute Optimizer, up to 93 with its paid enhanced metrics |
Commitments are where cloud capacity planning turns into a budget decision. AWS Savings Plans commit you to a set amount of compute spend per hour for one or three years, and Azure reservations are one- or three-year terms. Azure allows exchanges and limits self-service refunds to $50,000 in a rolling twelve-month window. The safe pattern is to commit only to the baseline the forecast is confident about and leave peaks on demand, which is why the checklist reviews commitment coverage after the forecast rather than before it.
Headroom targets are a judgement, not a standard. Response times climb steeply as a resource approaches full use, so many teams plan to act when forecast peak passes 70–80% on compute and around 80% on storage, and hold enough spare that losing one host or node does not tip the rest over. Tune the lines to how quickly you can add capacity: the longer the lead time, the lower the line.
Keep services, owners, components and thresholds in a data set. The review’s service table fills from it, so every quarter starts from the same list and the same lines, and a changed threshold is updated once rather than in every copy of a spreadsheet.
A quarterly recurring schedule opens the review, and dynamic due dates count each phase from the start date so the sign-off lands before the budget deadline. Conditional logic shows hardware or cloud options from the hosting model, and adds the budget task only when it is needed.
The sign-off goes to the approver picked in Phase 1, and nothing moves on until they record a decision. Utilisation exports and the plan attach to their tasks, the activity trail shows who did what and when, and template versioning keeps a record when the method changes.
The quarterly review sits above the routine checks. Weekly disk and CPU readings come from the Server Maintenance Checklist, and the Monthly IT Maintenance Checklist surfaces link, licence and tenant trends worth carrying into Phase 3. When the plan approves new capacity, the build runs through the Server Setup & Provisioning Checklist. Capacity reclaimed in Phase 5 leaves through the Server Decommissioning Checklist, with the IT Asset Management Checklist keeping the register straight.
A capacity review is only as good as its reference data. CheckFlow Data Sets hold the service catalogue, owners and thresholds in one table that every linked checklist reads, and they can be kept in sync through the REST API or a CSV import from your monitoring or CMDB export.
It is the work of making sure each IT service will have the compute, storage, network and licences it needs to meet its performance targets over the coming year, at an acceptable cost. It combines utilisation history with what the business plans to do, turns both into a forecast, and ends in decisions: reclaim, resize, buy, commit to cloud spend, or accept a known risk. ITIL 4 covers it under the capacity and performance management practice.
Quarterly suits most organisations: often enough to catch a trend before it becomes urgent, and rare enough to gather three months of data between reviews. Time one of the four runs to finish before the annual budget is set, so capacity spend is planned rather than requested mid-year. Add an unscheduled review for any large business event, such as an acquisition or a major launch.
There is no universal figure. A common starting point is to act when forecast peak passes 70–80% for CPU and memory or about 80% for storage, then lower the line where lead times are long or the service is critical. Measure against peaks and the 95th percentile rather than averages, and check the figure still holds with one host or node out of service.
Start with the growth rate each component shows over at least a quarter, including its busiest period. Add known step changes from the business, such as headcount, new sites and launches, and from IT, such as migrations and new applications. Project each service four quarters ahead, compare the result with its headroom line, and check the breach date against how long it takes to add capacity.
Yes, although the question changes from “will we run out?” to “what should we pay for?”. Autoscaling removes most shortfalls, but not quota limits, and it scales cost along with load. Cloud planning is about rightsizing over a window that includes the peak, covering the steady baseline with one- or three-year commitments, and raising quotas before the forecast needs them.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
