Capacity reviews usually happen after the pager goes off. Here is how a weekly forecast workflow flags the disk and CPU limits you will hit next month.
Most infrastructure teams do capacity planning twice a year, in a spreadsheet, with numbers that are already stale. Meanwhile the limits that actually hurt, a database volume or a connection pool, creep up quietly until a launch week pushes them over. Automated capacity forecasting replaces that spreadsheet ritual with a weekly report that tells you what will run out and when.
See the pattern in action, tap through the tabs below:
[2026-10-02 capacity] why reviews come too late
The bottleneck: capacity is checked when something breaks. A disk fills on a Saturday, a launch doubles traffic, and the team learns the limit from the pager instead of a chart.
The outcome: every Monday a short report lists which services will cross their limits in the next 45 days, with the evidence attached and a ticket already open.
[config] the whole workflow in one file
workflow: automated-capacity-forecast
schedule: "0 6 * * 1" # every Monday, 06:00
inputs:
- metric: node_cpu_utilization_p95
source: prometheus
lookback: 90d
- metric: disk_used_bytes
source: prometheus
lookback: 90d
- calendar: release_and_marketing_events
horizon: 45d
forecast:
method: seasonal_trend # weekly and daily seasonality
interval: 0.8
agent:
role: capacity_analyst
tools: [query_metrics, run_forecast, open_ticket]
rules:
- never resize anything, only open a ticket
- cite the metric query behind every claim
- flag any service where p95 crosses 80 percent in the horizon
output:
ticket_if: days_to_threshold < 30
post_to: "#capacity-review"
[06:00 monday] one simulated run
$ capacity-agent run --env prod [06:00:02] pulling 90d of p95 CPU, disk, queue depth for 41 services [06:00:19] forecast complete, 80% interval, horizon 45d [06:00:20] checkout-api cpu p95 62% -> 81% by Nov 14 (launch week) [06:00:20] pg-orders disk 71% -> 88% by Nov 02 [06:00:21] search-index stable, no threshold crossing [06:00:23] ticket CAP-212 opened: pg-orders disk, 31 days, evidence attached [06:00:24] ticket CAP-213 opened: checkout-api cpu, 43 days, evidence attached [06:00:25] summary posted to #capacity-review (2 risks, 39 services clear)
[checklist] first week
1. Pick the three resources that have hurt you before (disk, database connections, CPU).
2. Export 90 days of history for each.
3. Run a plain trend forecast by hand and compare it with what really happened.
4. Only then let an agent write the weekly summary and open tickets.
The bottleneck: capacity is a surprise
The pain is not a lack of metrics. You already collect them. The pain is that nobody has time to look at 90 days of trend lines across 40 services every week. So the review gets skipped, and the first real signal is an alert at 2 a.m.
Three symptoms show up on teams that need this workflow:
- Disk or storage alerts that fire with less than a day of runway.
- Launch and campaign dates that nobody connects to infrastructure headroom.
- Cloud bills that jump because someone over-provisioned in a panic.
What the workflow does
Every week, the workflow pulls recent history for the resources that matter, projects it forward, and reports only the services likely to cross a threshold. Quiet services stay quiet. The output is short enough that a human actually reads it.
- Collect: 90 days of p95 CPU, disk growth, memory and queue depth.
- Project: a 45 day forecast that accounts for weekly and daily cycles.
- Explain: a plain-language note per risky service, with the query that backs it.
- Route: a ticket for anything under 30 days of runway, a chat summary for the rest.
How it's built
This is the implementation detail, and it is deliberately boring. A scheduler (cron, a CI job or a workflow tool such as n8n) triggers the run. Metrics come from Prometheus, whose predict_linear function handles simple linear growth like disk. For seasonal traffic, a forecasting library such as Prophet fits daily and weekly patterns. An LLM agent then does the part humans dislike: reading the numbers, writing the summary, and opening the ticket.
The key design choice is that the model never does the math. The forecast comes from a deterministic tool, and the agent only narrates and routes. That keeps the numbers auditable. Google's SRE book makes the same point about intent-based capacity planning: state the requirement, then derive the resources.
Guardrails that keep it trustworthy
- Read-only by default. The agent opens tickets. It never resizes, scales or deletes anything.
- Show the evidence. Every claim links to the query that produced it.
- Report the interval. A forecast of 81% with an 80% interval is a range, not a promise. Say so.
- Feed it the calendar. Launches and sales are the events that break trend lines, so give the agent that context.
Where to start this week
Do not begin with 41 services. Choose the three resources that have already paged you, run the forecast by hand, and check it against history. If the prediction would have caught your last incident, automate the weekly run. If not, fix the inputs first. Teams that follow this path usually have a trustworthy report within two or three weeks.
FAQ
How much history does capacity forecasting need?
Ninety days is a practical minimum for weekly cycles. If you have a yearly peak such as a holiday season, include last year's data so the model can see it.
Can an AI agent scale my infrastructure automatically?
It can, but it should not start there. Begin with tickets and recommendations, then allow automated changes only for low-risk, reversible actions.
What is the difference between forecasting and autoscaling?
Autoscaling reacts to load that already exists. Forecasting warns you about limits that autoscaling cannot fix, such as disk growth, database connections and quota ceilings.
Want this workflow built for your team? The DevOps Boot Camp walks through it step by step, and you can browse everything else in our courses.
