A Capacity Planning Prompt That Forecasts Real Headroom

Capacity planning fails in one of two directions. Either you over-provision and burn money on idle headroom, or you under-provision and find out during a traffic spike that there was no runway left. Both come from the same root: the forecast lives in someone's head or a stale spreadsheet, and nobody recomputes it until something breaks. A capacity planning prompt turns that forecast into a repeatable artifact you regenerate whenever the numbers move.

The prompt that earns reuse takes current utilization, a growth rate, and a target headroom, then returns a runway, the scale-up triggers to wire into alerts, and a sizing recommendation. Numbers in, a plan out. Same shape every service.

What a capacity planning prompt produces

A capacity planning prompt is a reusable AI prompt that converts utilization, growth, and headroom inputs into a forecast: when capacity runs out, what triggers to set, and how much to add. The locked output contract is the point, because a forecast you can't compare across services is just a guess with a chart.

The published guidance is strategic, not actionable. TechTarget's AI capacity-planning tip argues correctly that linear models break on bursty workloads and recommends probabilistic, scenario-based forecasting, but it gives no numbers and no prompt. Introl's capacity guide is GPU-fleet-buying content for data centers, not the runway math a normal service team needs. The reusable prompt is the missing piece.

What you can do with this prompt

• Project how many weeks of runway a service has at its current growth rate.
• Compute the scale-up trigger that fires before you hit the headroom floor.
• Recommend a sizing increase that restores target headroom.
• Run best-case, expected, and worst-case growth scenarios in one pass.
• Produce a consistent forecast across every service so planning isn't ad hoc.

Anatomy of the prompt pack

Variables
  {{resource}}          – what's being sized: CPU, memory, connections, GPU
  {{current_util}}      – measured utilization now (%, or absolute)
  {{growth_rate}}       – weekly/monthly growth, with the basis
  {{target_headroom}}   – free capacity to keep, e.g. 25%
  {{provision_lead}}    – how long it takes to add capacity

Prompt
  Role: capacity planner forecasting runway from real utilization.
  Task: project the runway, set triggers, recommend sizing.
  Output contract (locked):
    1. Runway        – weeks until target headroom is breached
    2. Scale trigger – utilization % that should fire a scale-up
    3. Sizing        – capacity to add to restore {{target_headroom}}
    4. Scenarios     – low / expected / high growth runways
    5. Assumptions   – every number the model assumed vs was given

Headroom is a variable, not a constant. The common starting point is 20 to 30% free capacity, more for critical-path resources, but the right figure depends on your {{provision_lead}}: if adding capacity takes a week, your trigger has to fire a week before you'd run dry. The prompt computes the trigger from the lead time rather than hardcoding a number.

How models behave on a forecast

Claude is the most careful about separating given numbers from assumed ones, which matters because a forecast built on a hidden assumption is a landmine. GPT-4o produces tidy scenario tables but will sometimes apply linear growth even when you describe a bursty pattern; tell it to model the high scenario as a spike, not a slope. Gemini is fast at the arithmetic but occasionally reports the trigger as a date without showing the utilization percentage, so ask for both.

The forecast is only as honest as the growth rate you feed it. Garbage growth assumption, garbage runway. No model fixes that.

Prompt-craft patterns

Pattern 1 — show the assumptions. Make the model declare what it invented.

End with an "Assumptions" section listing every number you assumed
versus every number from the variables. If you assumed a growth
shape, name it.

Pattern 2 — trigger from lead time. Tie the scale-up point to reality.

Compute the scale-up trigger so a scale-up started at that point
finishes before {{target_headroom}} is breached, given
{{provision_lead}}. Show the math.

Pattern 3 — three scenarios, not one. Force the spread.

Produce low, expected, and high growth runways. Model the high case
as a traffic spike if {{growth_rate}} describes bursty traffic.

The stance: a single linear runway number is a comforting lie. Real traffic spikes, and the forecast that matters is the worst-case one, not the average. Plan for the high scenario and the expected case takes care of itself. Optimistic single-line forecasts are how teams get paged for capacity at the worst possible moment.

Variables you'll set

Getting started

1. Pull current utilization for one resource and an honest growth rate.
2. Set {{target_headroom}} and, if you know it, {{provision_lead}}.
3. Run the prompt on Claude and read the Assumptions section first.
4. Wire the scale-up trigger into your alerting.
5. Recompute when growth shifts or after any architecture change.
6. Reuse the prompt per resource so forecasts stay comparable.

The growth and latency numbers you feed this prompt come from your performance baselines, which is why it pairs with the SLO definition prompt, since a latency SLO under load is a capacity question in disguise. And the spikes you plan for are exactly what a gameday rehearses, covered in the chaos gameday plan prompt.

In the catalog, the Performance Regression Harness Agent Pack reads the baselines this forecast depends on, and the Observability Instrumentation Harness makes sure you emit the utilization metrics in the first place.

Forecast the worst case, back the trigger out from lead time, and recompute when the numbers move. Capacity planning isn't a once-a-year ritual. It's a prompt you rerun.