---
name: "Cloud Capacity Planning"
when_to_use: >-
  When right-sizing cloud resources or forecasting whether current capacity
  will hold up under growth. Use when: capacity planning, are we running out
  of capacity, resource forecast, growth planning, right-size this resource,
  over-provisioned, under-provisioned, quota check.
description: >
  Use this skill when right-sizing or forecasting capacity for cloud
  resources across whatever cloud platforms (Azure, DigitalOcean) are
  connected through the gateway. Covers identifying over-provisioned and
  under-utilized resources (Azure resource groups/quotas, DigitalOcean
  Droplets/Kubernetes/Databases), building a growth-trend-based capacity
  forecast, and — critically — the difference between a genuine capacity risk
  and normal variance that doesn't warrant action. Always use
  conduit__search_tools to discover which cloud platforms are actually
  connected before assuming a specific vendor.
---

# Cloud Capacity Planning

## Overview

Capacity planning answers two distinct questions that are easy to conflate:
"is this resource sized correctly right now" (right-sizing) and "will it
still be sized correctly in N weeks given its growth trend" (forecasting).
This skill covers both, across whatever cloud platform(s) an org has
connected, and is deliberately conservative about calling something a risk —
a capacity plan that cries wolf on every metric blip gets ignored.

This is infrastructure-substrate capacity — compute, storage, database, and
cluster headroom on the platforms themselves. It is not application-level
performance or SLO tracking (see `devops-pack`, if connected) and it is not
spend (see the `cloud-cost-management` skill, a related but separate
concern: a resource can be correctly sized and still be a cost problem, or
be under-provisioned and cheap).

## Discovering available tools first

Never assume which cloud platform is connected:

1. Call `conduit__search_tools` with a query like `"list resources"`,
   `"resource group"`, `"droplet"`, or `"quota"` to discover which cloud
   platform connector(s) are live and their actual tool names (e.g.
   `azure-mcp__group_resource_list`, `azure-mcp__quota`,
   `digitalocean__list_droplets`, `digitalocean__list_kubernetes_clusters`,
   `digitalocean__list_databases`).
2. More than one cloud platform can be connected (an org running both Azure
   and DigitalOcean). Cover all connected platforms; don't stop at the
   first.
3. Only call concrete tools that discovery actually returned.

## Key Concepts

### Right-sizing signals, per platform

| Platform | Over-provisioned signal | Under-provisioned signal |
|---|---|---|
| Azure | Resource group / subscription quota usage well below allocated quota (via `azure-mcp__quota`); Advisor recommendations flagging low-utilization VMs or oversized SKUs (via `azure-mcp__advisor`); sustained low CPU/memory/IOPS in `azure-mcp__monitor` metrics against an oversized SKU | Quota usage approaching the allocated limit; Advisor or `azure-mcp__resourcehealth` flagging throttling, sustained high utilization, or scale-limited resources |
| DigitalOcean | A Droplet or Database sized well above its sustained CPU/memory/disk usage; a DOKS node pool with persistently low node utilization; unattached or lightly used block storage | A Droplet or Database consistently near its CPU/memory/disk ceiling; a DOKS cluster with pods pending due to insufficient node capacity; a Database approaching connection-limit or storage-limit thresholds |

### Genuine capacity risk vs. normal variance

Do not flag a resource as at-risk from a single data point or a short window.
Apply this discipline:

1. **Require a trend, not a spike.** A single hour or day of elevated
   utilization (batch job, deploy, traffic burst) is normal variance. A
   metric that has climbed over multiple consecutive observation windows
   (e.g., week-over-week) is a trend worth forecasting against.
2. **Distinguish burst-tolerant from sustained-critical resources.** A
   Droplet that spikes to 95% CPU for ten minutes during a nightly job is
   fine. A database consistently running at 85%+ storage utilization with no
   cleanup planned is a real risk — it degrades gracefully into an outage,
   not a burst.
3. **State the observation window used.** Always name how much history the
   forecast is based on (e.g., "based on the last 30 days of `azure-mcp__monitor`
   data") — a forecast built on three days of data is weaker evidence than
   one built on ninety, and the reader needs to know which they're getting.
4. **When historical/trend data isn't exposed**, say so explicitly and
   report current utilization as a point-in-time snapshot rather than
   fabricating a trend line.

### Growth-trend-based forecasting

1. Pull utilization history for the resource over the longest available
   window the connected platform exposes.
2. Compute the trend direction and rate (e.g., "storage utilization has grown
   ~3%/week over the last 8 weeks").
3. Project forward to the point the resource would hit a critical threshold
   (e.g., 90% of allocated capacity) at the observed rate, and state that
   projected date as a range, not a false-precision single day — growth rates
   fluctuate.
4. Flag only resources whose projected exhaustion falls within a
   near-to-medium planning horizon (e.g., inside ~90 days) as needing
   near-term action; note longer horizons as "monitor, no action needed yet."

## Common Workflows

### Portfolio right-sizing sweep

1. Discover connected cloud platforms via `conduit__search_tools`.
2. Pull resource inventory (resource groups, Droplets, DOKS clusters,
   managed databases) per connected platform.
3. Pull utilization/quota data for each and classify:
   over-provisioned / right-sized / under-provisioned / insufficient data.
4. Return a ranked list — under-provisioned (real risk) first, then
   over-provisioned (savings/right-sizing opportunity), then a clean summary
   of correctly sized resources.

### Capacity forecast for a resource type

1. Discover connected platforms.
2. Scope to the requested resource type (compute, storage, database, or all)
   per the caller's request.
3. Pull the longest available utilization history for resources of that
   type.
4. Apply the trend-vs-variance discipline above and produce a forecast
   timeline per at-risk resource, plus a "no near-term risk" summary for the
   rest.

## Error Handling

### No cloud platform connector discovered

Say so explicitly: "No cloud platform connector (Azure, DigitalOcean) is
available through the gateway, so there's no capacity data to report." Do
not fabricate resource data.

### Platform connected but historical/trend data not exposed

Report current point-in-time utilization and state plainly that a
trend-based forecast wasn't possible — do not extrapolate from a single
reading.

### Ambiguous resource-type scope

If asked to scope to a resource type that doesn't map cleanly onto what's
connected (e.g., "database" requested but only compute platforms are
connected), say so and report what is available instead of silently
returning an empty result.

## Best Practices

- Always discover tools before calling them — never hardcode a vendor's tool
  name.
- Never call a metric blip a capacity risk — require a sustained trend across
  multiple observation windows.
- State the observation window and data source behind every forecast.
- Separate "needs action soon" from "worth tracking, not urgent" explicitly
  rather than presenting one undifferentiated risk list.
- Capacity and cost are related but distinct — this skill doesn't make
  spend judgments; hand those to `cloud-cost-management`.

## Related Skills

- [Network Health Sweep](../network-health-sweep/SKILL.md) — device/network
  health rather than cloud resource capacity
- [Cloud Cost Management](../cloud-cost-management/SKILL.md) — spend
  anomalies and reclaimable cost; a right-sized resource can still be a cost
  problem and vice versa