What this template is for
Incident response is the one Jira workflow where ‘a minute saved on triage’ is literally money. Every minute spent figuring out who owns what, which channel to post in, or whether the status page is updated is a minute of customer impact.
This template has two halves:
- Fields on the Incident create screen. A project admin configures these in Jira (Project settings → Screens) so the on-call engineer fills them in once when the incident is declared.
- Sub-tasks STM creates on every new Incident. An STM sub-task template plus an On Create Issue Executor turns the create event into a populated war-room checklist - acknowledge, status page, identify mitigation, verify, postmortem, action items.
The moment an on-call engineer acknowledges a page and opens the Incident ticket, the commander and severity fields are right there to fill in, and the sub-tasks are already created and waiting.
When to use it
Use this template the instant a production incident is declared - before mitigation, before investigation, before anything else. The template’s purpose is to remove decisions from the on-call engineer at the worst possible moment to be making decisions.
For internal-only issues with no customer impact (failed CI run, dev cluster degraded) use a regular task. Reserve the incident template for events that have or will have customer-visible impact.
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 | SEV2 - Checkout API 502 error rate elevated | Yes |
Severity | SEV2 | Yes |
Incident Commander (custom) | @alex.chen | Yes |
Communications Lead (custom) | @priya.patel | Yes |
Customer Impact | ~12% of checkout sessions failing | Yes |
Status Page Posted | Yes - https://status.example.com/incidents/abc | Yes |
Started At | 2026-05-19T14:32:00Z | Yes |
Detected At | 2026-05-19T14:36:00Z | No |
Mitigated At | 2026-05-19T15:11:00Z | No |
Resolved At | 2026-05-19T15:48:00Z | No |
Affected Service/s | checkout-api, payments-worker | No |
Detection Source | PagerDuty alert / customer report / synthetic check | No |
Communication Channel | #inc-2026-05-19-checkout | 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.
- Acknowledge page and open the incident war room (Slack/Zoom)
- Post initial status-page update within 15 minutes of detection
- Identify mitigation: rollback, feature flag, traffic shift, or hotfix
- Confirm mitigation in metrics and post resolved status-page update
- Capture timeline in the incident channel pin for the postmortem
- Schedule blameless postmortem within 5 business days
- File follow-up action items as linked tickets
Common questions
What's the difference between an incident ticket and a bug ticket in Jira?
An incident is a live customer-impacting event with a commander, severity, and communication cadence. A bug is a defect to be scheduled and fixed. Most incidents produce one or more bug or task tickets as follow-ups, but the incident ticket itself is the timeline record.
How should severity be defined for Jira incidents?
Define severity on customer impact, not on system internals. SEV1: total outage or data loss. SEV2: major feature unavailable or significant degradation. SEV3: minor feature degradation with a workaround. SEV4: internal issue with no customer impact. Severity drives paging rules and communication cadence.
Who should own an incident ticket?
The Incident Commander owns the incident ticket end-to-end - including reopening it for the postmortem. The Commander is rotational and explicit; never leave the assignee blank or the on-call rotation as a group. The Communications Lead is separate so the Commander can stay focused on mitigation.
What sub-tasks make sense on an incident ticket?
The minimum useful sub-tasks are: acknowledge, initial status page, identify mitigation, verify mitigation, postmortem scheduled, action items filed. STM Issue Templates can auto-create these via an On Create Issue Executor scoped to issue type Incident, so the on-call has a checklist instead of a blank page.
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 →