What this template is for
Performance regressions are bugs that don’t break a feature - they make it slower. Teams that treat them as ‘just bugs’ miss two things: the baseline data is crucial (without it, you can’t even confirm a regression exists), and the time-to-detect is often much longer than functional bugs (a slow page is harder to notice than a broken page).
This template fixes both:
- Required metric fields on the create screen - affected metric, baseline value, current value, regression-started timestamp, suspected commit range. These force the regression to be confirmed with data before anyone starts investigating, and give the investigator a head start by capturing the commit range up-front.
- STM-created investigation sub-tasks - confirm, reproduce, bisect, identify root cause, fix, verify return to baseline, document for prevention. The verify-return-to-baseline step is the one teams skip; without it, ‘we fixed it’ is never confirmed.
When to use it
Use this template whenever a measured metric has degraded by more than a noise threshold and that degradation is plausibly tied to a recent change. Use the bug-report template instead for functional defects, and the incident-response template for live, customer-impacting issues (some performance regressions are incidents - those start as incidents and produce regression tickets as follow-up work).
Don’t use this template for general performance optimisation that isn’t a regression. Use a story for proactive perf work.
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 | Checkout API p99 latency up 35% since deploy 4.13.0 | Yes |
Affected Metric (custom) | checkout_api_request_duration_seconds (p99) | Yes |
Baseline Value (custom) | p99 = 220ms (week before regression) | Yes |
Current Value (custom) | p99 = 297ms (week of regression) | Yes |
Regression Started (custom) | 2026-05-15 ~14:00 UTC - aligns with deploy 4.13.0 | Yes |
Suspected Commit Range (custom) | abc123..def456 (deploy 4.13.0) | Yes |
Customer Impact (custom) | Estimated business effect: conversion drop, complaints, SLA risk | Yes |
Reproduction Steps (custom) | How to reproduce in load testing or in prod metrics | No |
Linked Dashboard | Grafana panel showing the regression | No |
Linked Deploy / Release | RELEASE-4130 | No |
Priority | Tied to customer-impact magnitude, not always High | 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.
- Confirm regression with at least two independent metric sources (APM + customer signal)
- Capture full reproduction in staging or a load test - rule out environmental drift
- Bisect the suspected commit range if not obvious from the data
- Identify root cause - profiler, query analysis, network trace, etc.
- Implement fix - new story or directly on this ticket if small
- Verify the metric returns to baseline in production for 24+ hours
- Document root cause and prevention in the postmortem if SEV-worthy
Common questions
What's the difference between a performance regression and a regular bug in Jira?
A performance regression has measurable metrics with a baseline. A regular bug has a functional defect. The regression template forces capture of before/after values and the suspected commit range up-front, so investigation starts with data rather than guesses. Tracking regressions separately also makes them queryable so you can spot recurring patterns.
How do you find the commit that caused a performance regression?
Bisect: deploy each commit in the suspected range one at a time, measure the metric, narrow down. For a 10-commit deploy that's 3-4 cycles. Time-consuming but reliable. Build infrastructure to do this automatically if your team has regular performance regressions - the manual approach doesn't scale past a few per quarter.
Should performance regressions block the next release?
It depends on customer impact. A 5ms p99 increase usually doesn't block; a 50% increase usually does. The customer-impact field on the ticket forces an explicit conversation about this. 'Performance regression' isn't a unique severity level - it's a class of defect that maps to your existing severity scheme via measured impact.
How do you prevent performance regressions in Jira-tracked work?
Add performance acceptance criteria to stories that touch hot paths. Make performance benchmarks part of CI on critical services. Track regressions as a distinct ticket type so you can measure how often they happen and where. A team that ships 10 regressions a quarter has a systemic problem that ticket hygiene won't solve.
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 →