What this template is for
Infrastructure changes have outsized blast radius because they affect every application running on the resource. A wrong-sized RDS, a misconfigured security group, an over-broad IAM grant - any one of them can produce an incident that touches every service in the account.
This template applies the change-management contract to infrastructure: explicit IaC diff, blast radius, rollback path, maintenance window, CAB approval. The Terraform plan output goes on the ticket as text so reviewers can confirm the diff matches the intent before approval.
When to use it
Use this template for any infrastructure or network change that affects production:
- Resource resize, replace, or destroy
- Network ACL, security group, or routing changes
- IAM policy and role changes
- DNS record changes (especially for production hostnames)
- Cross-account or cross-VPC topology changes
Routine credential rotation or auto-scaling adjustments within pre-approved bounds can use a lightweight standard-change variant.
Sub-task breakdown
STM Issue Templates creates the pre-change / CAB / apply / validate / rollback / post-change sub-tasks automatically when the change ticket is created. For projects that already use Custom Fields for rollback plan or blast radius on application changes, reuse them here so the change-management reporting stays consistent across the application and infrastructure layers.
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 | Resize prod RDS payments-db from db.r6g.large to db.r6g.xlarge | Yes |
Infrastructure Domain (custom) | AWS / GCP / Azure / on-prem / network / DNS | Yes |
Change Type (custom) | Resize / Add resource / Remove resource / Network ACL / IAM | Yes |
IaC Pull Request (custom) | https://github.com/org/infra/pull/812 | Yes |
Terraform Plan Output (custom) | Attach text of terraform plan | Yes |
Blast Radius (custom) | All payments traffic; ~5 min replica lag during cutover | Yes |
Rollback Plan (custom) | Revert IaC PR; previous instance class remains available | Yes |
Maintenance Window | 2026-05-24 02:00-04:00 UTC | Yes |
CAB Approval (custom) | Approved by @cab-chair 2026-05-23 | No |
Implementer | @oncall-platform | No |
Reviewer | @platform-tech-lead | No |
Linked Capacity Ticket | PROJ-1402 | 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.
- Pre-change: confirm Terraform plan matches the intended change exactly
- Pre-change: notify affected service owners and post in #change-calendar
- CAB review (skip for standard changes pre-approved by infra policy)
- Execute terraform apply during the maintenance window
- Validate: monitoring green, smoke tests pass, replica lag within budget
- If validation fails: execute rollback by reverting the IaC PR
- Post-change: update architecture diagram and CMDB if topology changed
Common questions
What is an infrastructure change request in Jira?
It is a change ticket scoped to infrastructure or network resources - typically Terraform, CloudFormation, or Pulumi changes - rather than application code. The ticket captures the IaC PR link, the planned diff, blast radius, rollback path, and validation criteria. It is the audit trail that turns 'someone ran terraform apply' into an accountable, reversible event.
Should every Terraform change go through a Jira change ticket?
Every production-impacting Terraform change, yes. Pre-approved standard changes (rotating credentials, adjusting auto-scaling within bounds) can use a lightweight version of this template, but the audit-trail value is the same: when a change later causes an issue, the ticket is where the on-call looks first.
How do you handle emergency infrastructure changes?
Set Change Type to Emergency and bypass the standard CAB lead time, but do not skip the rollback plan or the validation criteria. Emergency changes are higher risk precisely because the team is under pressure; the discipline of writing down 'what would I roll back to' is more valuable, not less, in an emergency.
Can you auto-create the infrastructure change sub-task checklist?
Yes - configure an [STM Issue Templates](/stm/) Executor that fires on creation of an Infrastructure Change ticket and lays down the pre-change / CAB / apply / validate / rollback / post-change sub-tasks. The implementer never has to remember the order, and the audit trail is consistent across changes.
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 →