How to Set Up Incident Management in Jira
Jira Service Management (JSM) has dedicated incident management features, but many teams run incidents through Jira Software because that is where engineers already work. This guide covers how to set up a structured incident workflow in Jira Software for product engineering teams who want incident tracking alongside their feature work.
The approach uses a dedicated issue type, severity fields, custom workflow, and automation rules to handle the full incident lifecycle from detection to post-mortem.
Step-by-step guide
Create an Incident issue type
Go to Project Settings > Issue Types and create a new issue type called "Incident" with a distinct icon (red flame or warning icon). Add custom fields: Severity (select: SEV-0, SEV-1, SEV-2, SEV-3), Start Time (datetime), Resolution Time (datetime), Services Affected (multi-select), and Root Cause (paragraph text). These fields drive severity SLAs and post-mortem reporting.
Configure the incident workflow
Create a dedicated workflow for the Incident issue type: Reported > Triaging > Mitigating > Monitoring > Resolved > Post-Mortem Complete. The Resolved → Post-Mortem Complete transition requires the Root Cause field to be filled in, enforcing documentation before closure. Map this workflow to the Incident issue type in your workflow scheme.
Set up automation for escalation
In Project Settings > Automation: create a rule triggered on issue creation where Severity = SEV-0 or SEV-1, with action to send a Slack notification to #incidents with the issue title, severity, and assignee. Create a second rule: when an Incident stays in Triaging for more than 10 minutes, send an escalation alert to the on-call lead.
Create an Incidents board
Create a Jira Kanban board filtered to show only Incident issue types. Configure columns matching your workflow. This board is the command center during an active incident. Sort by Severity within each column so SEV-0 items are always at the top.
Track post-mortems with linked issues
When an incident moves to Resolved, manually create a linked issue of type "Task" called "Post-Mortem: [incident summary]." Set the due date to 48 hours from resolution. Link it to the incident with "Post-mortem for." Create a Jira template for post-mortems with sections: Timeline, Root Cause, Contributing Factors, Action Items.
Common mistakes
Filing incidents as regular bugs
Incidents and bugs have different urgency, workflow, and reporting needs. An incident requires a severity SLA, real-time escalation, and a post-mortem. A bug requires triage and grooming. Using the same issue type for both breaks your reporting and escalation logic.
Severity assigned too late
Severity must be assigned at creation — within 5 minutes. Many teams assign severity only after investigation, which means SEV-0 incidents sit unescalated for 30 minutes. If you are unsure, assign SEV-1 and downgrade if appropriate. Never leave severity blank.
Post-mortems without action items
A post-mortem that ends with "we will be more careful" produces zero improvement. Every post-mortem must produce at least one Jira ticket with a named owner and due date. Link the action item ticket to the post-mortem. Track completion in your next engineering sync.
Tips
Create a Jira dashboard for incidents: open incidents by severity, mean time to resolution by SEV level, incidents per month trend
Use Jira's Slack integration to let anyone file an incident from a Slack message shortcut
Review incident trends quarterly to identify services or features that generate repeated incidents
How Vantage helps
Vantage generates tickets with detailed acceptance criteria that reduce ambiguity during development. Clear requirements mean fewer incidents caused by misunderstood specs. When an incident does occur, the Vantage PRD and requirements provide engineers with the original design intent — essential context for accurate root cause analysis.