Capacity Planning Forecast Template

Overview

Traffic grows, but infrastructure does not grow by itself. Most outages are not caused by bad code — they are caused by systems that hit a wall nobody measured. Capacity planning is the discipline of looking ahead: how much traffic will we have in six months, what resource will run out first, and what will it cost to stay ahead of demand? A capacity forecast turns panic-driven scaling into a scheduled, budgeted, and tested operation.

When to Use

• For alternatives, see Capacity Planning — Forecast, Scale.

Use this template when:

• You are entering a growth phase (marketing campaign, product launch, seasonal spike)
• A service is approaching 60-70% utilization of any critical resource
• You need to justify infrastructure spending to finance or leadership
• You want to move from reactive scaling to proactive planning
• You are evaluating a move from vertical to horizontal scaling

Prerequisites

Before creating a capacity forecast:

• Baseline metrics exist: CPU, memory, disk I/O, network throughput, request rate, latency
• Historical traffic data is available for at least the last three months
• Growth assumptions are documented (marketing plans, user acquisition targets, feature launches)
• Cost data is available: cloud provider bills, reserved instance pricing, licensing
• The team agrees on what “full” means (80%? 90%? 100% with headroom?)

Solution

# Capacity Planning Forecast: `<System / Service>`

> Author: ______ | Date: ______ | Review date: ______
> Service owner: ______ | Team: ______ | Forecast horizon: ______

## 1. Current State

| Metric | Current | Peak (last 30d) | Limit | Headroom |
|--------|---------|-----------------|-------|----------|
| Requests / sec | ______ | ______ | ______ | ______ |
| CPU utilization (%) | ______ | ______ | ______ | ______ |
| Memory utilization (%) | ______ | ______ | ______ | ______ |
| Disk I/O (MB/s or IOPS) | ______ | ______ | ______ | ______ |
| Network throughput (Gbps) | ______ | ______ | ______ | ______ |
| Database connections | ______ | ______ | ______ | ______ |
| Storage used (GB) | ______ | ______ | ______ | ______ |
| Queue depth / backlog | ______ | ______ | ______ | ______ |

**Current infrastructure:**
- ______ instances at ______ size
- ______ databases at ______ tier
- ______ cache nodes
- ______ load balancers
- Estimated monthly cost: ______

## 2. Growth Assumptions

| Driver | Expected Change | Timeframe | Confidence |
|--------|-----------------|-----------|------------|
| ______ | ______ | ______ | High / Medium / Low |
| ______ | ______ | ______ | High / Medium / Low |
| ______ | ______ | ______ | High / Medium / Low |

**Key assumptions:**
- [ ] ______
- [ ] ______

## 3. Traffic Projections

| Period | Projected RPS | Projected MAU | Growth Rate |
|--------|---------------|---------------|-------------|
| Current | ______ | ______ | — |
| +3 months | ______ | ______ | ______ |
| +6 months | ______ | ______ | ______ |
| +12 months | ______ | ______ | ______ |

## 4. Resource Forecast

| Resource | Current | +3m | +6m | +12m | First to Hit Limit? |
|----------|---------|-----|-----|------|---------------------|
| CPU | ______ | ______ | ______ | ______ | Yes / No |
| Memory | ______ | ______ | ______ | ______ | Yes / No |
| Disk I/O | ______ | ______ | ______ | ______ | Yes / No |
| Network | ______ | ______ | ______ | ______ | Yes / No |
| DB connections | ______ | ______ | ______ | ______ | Yes / No |
| Storage | ______ | ______ | ______ | ______ | Yes / No |

## 5. Scaling Plan

### Short Term (0-3 months)
- [ ] ______
- [ ] ______

### Medium Term (3-6 months)
- [ ] ______
- [ ] ______

### Long Term (6-12 months)
- [ ] ______
- [ ] ______

## 6. Cost Projection

| Scenario | Monthly Cost | Annual Cost | Notes |
|----------|-------------|-------------|-------|
| Do nothing | ______ | ______ | Risk of outage |
| Minimum viable | ______ | ______ | Just ahead of demand |
| Comfortable headroom | ______ | ______ | 30-40% buffer |

## 7. Risk Assessment

| Risk | Likelihood | Impact | Mitigation |
|------|------------|--------|------------|
| Growth exceeds forecast | ______ | ______ | ______ |
| Cloud provider limits | ______ | ______ | ______ |
| Scaling takes longer than expected | ______ | ______ | ______ |
| Budget not approved | ______ | ______ | ______ |

## 8. Action Items

| Task | Owner | Due Date | Status |
|------|-------|----------|--------|
| ______ | ______ | ______ | ______ |

## 9. Appendix

- Links to dashboards: ______
- Historical incident data: ______
- Related ADRs or design docs: ______

Explanation

The template separates measurement (current state) from prediction (growth assumptions and traffic projections) from decision (scaling plan and cost projection). The resource forecast table highlights which resource will hit its limit first — this is the bottleneck that determines your scaling timeline. The cost projection frames the technical plan in business terms, making it easier to secure budget.

Capacity Forecast Dashboard Example

=== Capacity Forecast Dashboard — Q3 2026 ===

CURRENT STATE (as of 2026-07-11):
  CPU utilization (avg):     42%
  CPU utilization (peak):    68%
  Memory utilization (avg):  55%
  Memory utilization (peak): 78%
  Disk usage:                3.2 TB / 5 TB (64%)
  Network throughput (avg):  120 Mbps
  Network throughput (peak): 450 Mbps
  DB connections (avg):      45 / 100
  DB connections (peak):     82 / 100

GROWTH ASSUMPTIONS:
  User growth rate:          8% / month (based on last 6 months)
  Traffic growth rate:       12% / month (traffic grows faster than users)
  Data growth rate:          50 GB / month
  Seasonal peak factor:      2.5x (Black Friday, holiday season)

6-MONTH PROJECTION:
  Month    | CPU Peak | Mem Peak | Disk    | DB Conn Peak
  ---------|----------|----------|---------|-------------
  Aug 2026 | 72%      | 82%      | 3.7 TB  | 88
  Sep 2026 | 78%      | 86%      | 4.2 TB  | 94
  Oct 2026 | 85%      | 91%      | 4.7 TB  | 102 (OVER!)
  Nov 2026 | 95%      | 96%      | 5.2 TB  | 115 (OVER!)
  Dec 2026 | 98%      | 98%      | 5.7 TB  | 125 (OVER!)
  Jan 2027 | 100%+    | 100%+    | 6.2 TB  | 140 (OVER!)

BOTTLENECK: Database connections hit limit in October 2026
ACTION: Increase connection pool to 200 by September 2026

BOTTLENECK: Disk hits 5 TB limit in November 2026
ACTION: Add 3 TB storage by October 2026

BOTTLENECK: CPU hits 90% in November 2026 (seasonal peak)
ACTION: Add 4 instances to auto-scaling group by October 2026

Variants

Context	Adjustments	Notes
Database-specific	Add query throughput, index growth, replication lag, and connection pool limits	Databases hit limits differently than compute
Storage-heavy systems	Add data retention policies, compression plans, and tiered storage costs	Storage grows predictably but is expensive
Event-driven / queue-based	Add throughput per shard, consumer lag, and dead-letter queue growth	Queues hide backpressure until they overflow
Multi-region	Add cross-region replication bandwidth and per-region capacity	Each region may have different growth
Serverless	Add invocation counts, concurrency limits, and cold-start frequency	Serverless limits are different from instance limits

What Works

1. Forecast monthly, review quarterly — assumptions change; refresh the forecast before it becomes fiction
2. Use percentiles, not averages — p99 latency and peak CPU matter more than mean values
3. Include a “do nothing” scenario — it makes the cost of inaction explicit
4. Test your scaling plan — run a load test that simulates your 6-month projection before you need it
5. Share the forecast broadly — product, finance, and engineering should all see the same numbers

Common Mistakes

1. Planning based on averages — a system at 50% average CPU can be at 95% during peak hours
2. Ignoring the database — compute scales horizontally; databases often do not
3. Forgetting about downstream services — scaling your API is useless if your cache or database cannot keep up
4. No confidence levels on assumptions — marketing campaigns fail; build scenarios for high, medium, and low growth
5. Waiting until 90% utilization — by then you are already in emergency mode; plan at 70%

Troubleshooting

• Instance is unreachable: check security groups, routes, DNS, and health status in the provider console. Verify that the OS firewall is not blocking the port.
• Provisioning fails consistently: inspect the init script, IAM roles, and image availability. A missing permission is the most common root cause.
• Resource exhaustion alerts: correlate CPU, memory, disk, and network metrics.
• Backup restore does not work: test restores regularly. A backup that cannot be restored is not a backup.
• Configuration drift: compare running instances with the infrastructure-as-code definition. Recreate from the canonical definition when in doubt.

Further Reading

• Official documentation: check the current reference for the framework or tool used.
• Related guides: explore the capacity-planning and forecasting guides for deeper coverage.
• Complementary patterns: review design patterns applicable to your technology stack.
• Public postmortems: study real incidents from teams that faced similar production issues.

Production Notes

• Deploy gradually using canary or blue-green to catch regressions early.
• Configure alerts for error rate, p99 latency, and failure rate before enabling in production.
• Document the rollback in the runbook; test the procedure in staging at least once per quarter.
• Review structured logs with correlation IDs to trace requests end-to-end during incidents.

Key Takeaways

• Apply capacity planning forecast template when you need a practical solution for your use case.
• Monitor performance after implementation; measure latency, errors, and resource usage before and after.
• Check the Troubleshooting section for common failures; most have documented root causes with fixes.
• Keep dependencies updated and run tests in CI to prevent production regressions.

Common Production Pitfalls

• Leaving required fields blank or using vague one-word answers.
• Filling the document once and never updating it after scope or decisions change.
• Storing the document where the team does not look during incidents or reviews.
• Not assigning an owner, due date, or review cadence.
• Copying boilerplate without removing sections that do not apply.
• Skipping version control, which makes rollback and accountability impossible.
• Failing to link the document to related decisions or follow-up actions.
• Avoiding quarterly reviews that would retire stale or unused sections.