What this template is for
Capacity planning is the cheap version of incident response. A 30-minute review per resource per quarter prevents the 4-hour incident when CPU finally crosses 95% during a Black Friday surge. Teams that do capacity planning rarely have capacity-driven outages; teams that don’t have them regularly.
This template makes the review structured and recurring. Each ticket is one resource, one period, one recommendation. Over time the chain of tickets is the resource’s growth history.
When to use it
Use this template:
- Quarterly for every tracked production resource (databases, caches, queue brokers, key services)
- Monthly for resources currently above 70% utilisation
- Before any known growth event - region launch, large customer onboarding, marketing surge
For resources with auto-scaling that has never hit its ceiling, an annual review is fine.
How to set it up in Jira
Create a Capacity Review issue type with the fields above. Use STM Issue Templates to create the quarterly ticket per tracked resource on a schedule, with the standard sub-task checklist (pull metrics, identify drivers, project, recommend, link change, schedule next) laid down automatically. The recommended action sub-task should link to a change ticket if action is needed, which closes the loop between capacity planning and execution.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Q3 2026 capacity review - payments-db | Yes |
Resource (custom) | payments-db (RDS r6g.large) | Yes |
Review Period (custom) | 2026-Q3 | Yes |
Current Utilisation (custom) | CPU 64% p95, IOPS 11k/15k, storage 380/500 GB | Yes |
Growth Driver (custom) | 20% MoM transaction growth from new region launch | Yes |
Projected Utilisation (custom) | CPU 88% p95 by end of Q3 | Yes |
Headroom Threshold (custom) | 70% sustained or 85% peak | Yes |
Recommended Action (custom) | Resize to r6g.xlarge in week 3 of Q3 | Yes |
Cost Impact (custom) | +$420/month | No |
Owner | @platform-tl | No |
Linked Change Ticket | PROJ-1450 | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Pull utilisation metrics for the review period (CPU, memory, IOPS, storage, network)
- Identify growth drivers - new features, launches, seasonal effects
- Project utilisation against headroom thresholds for the next two quarters
- Recommend an action: scale up, scale out, optimise, or do nothing
- If action is needed, open a change ticket and link it
- Schedule the next review one quarter out
Common questions
What is capacity planning in a Jira workflow?
Capacity planning is the recurring review that compares current resource utilisation against projected growth and headroom thresholds, and decides whether to scale, optimise, or wait. As a Jira workflow, it lives as a ticket per resource per quarter, with explicit fields for current usage, projection, and recommended action - so capacity decisions are auditable rather than vibes-based.
How often should capacity reviews happen?
Quarterly for most services, monthly for resources that are within 20% of saturation, and ad-hoc when a known growth event (region launch, customer onboarding, marketing campaign) is approaching. The cadence should be fast enough that you act before saturation, not so fast that the review becomes box-ticking.
What headroom should you keep on a saturated resource?
A common rule is 30% headroom at p95 and at least 15% headroom at peak. Below those thresholds, normal variance and incident-driven traffic spikes start causing user-visible latency. The exact numbers depend on the resource and the cost of scaling - stateful databases need more headroom than stateless application servers.
How do you remember to run capacity reviews?
Make them recurring tickets, not calendar reminders. [STM Issue Templates](/stm/) can create the quarterly review ticket for each tracked resource on a schedule, with the standard sub-task checklist already laid down. The reviewer opens the ticket, pulls the metrics, and runs the same five-step assessment every quarter.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →