| 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:
- 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).
- 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.
- 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:
- 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.
- 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.
- 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.
- 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
- Pull utilization history for the resource over the longest available
window the connected platform exposes.
- Compute the trend direction and rate (e.g., "storage utilization has grown
~3%/week over the last 8 weeks").
- 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.
- 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
- Discover connected cloud platforms via
conduit__search_tools.
- Pull resource inventory (resource groups, Droplets, DOKS clusters,
managed databases) per connected platform.
- Pull utilization/quota data for each and classify:
over-provisioned / right-sized / under-provisioned / insufficient data.
- 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
- Discover connected platforms.
- Scope to the requested resource type (compute, storage, database, or all)
per the caller's request.
- Pull the longest available utilization history for resources of that
type.
- 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 — device/network
health rather than cloud resource capacity
- Cloud Cost Management — spend
anomalies and reclaimable cost; a right-sized resource can still be a cost
problem and vice versa
