ITSM Process Owners and Service Delivery Managers tracking resolution times across a matrix of priorities and work item types - where a Critical Incident has a 4-hour target but a Major Service Request gets 3 business days.
Resolution time is your most important SLA metric - it’s what your customers care about and what your SLA contracts define. But “resolve it fast” means very different things depending on the ticket. A security incident (Critical) needs resolution in hours. A password reset request (Low) can wait a day. And the clock should pause when you’re waiting for the customer to respond.
Define one SLA per priority × work item type combination, using JQL to target the exact segment and pause conditions to stop the clock whenever your team is waiting on the customer. The Copy SLA feature lets you build the full matrix in minutes.
Before creating SLAs, define which combinations of priority and work item type need separate targets. A recommended starting structure:
| Goal name | JQL Filter | Goal | Goal Type |
|---|---|---|---|
| [IM] TTR - Incident Critical | priority = Highest AND issuetype = Incident |
4 hours | Duration |
| [IM] TTR - Incident Major | priority = High AND issuetype = Incident |
8 hours | Duration |
| [SR] TTR - Service Request Major | priority = High AND issuetype = "Service Request" |
3 days | Business Days Offset |
| [SR] TTR - Service Request Low | priority = Low AND issuetype = "Service Request" |
5 days | Business Days Offset |
In the SLA Time Management app, open the SLAs tab and click Add SLA.
Fill in the basic information:
Back to App page
Time to resolutionIn the Goals section, click Add Goal.
Enter a Goal name (e.g. 4 hour resolution).
Select your Calendar.
Set the Goal type:
Enter the JQL filter:
priority = Highest AND issuetype = Incident
JQL supports any Jira field. You can combine priority, work item type, project, labels, components, and more.
Business Days Offset is ideal for Service Requests - it sets the deadline at the end of the Nth working day. Pause conditions stop tracking time but do not shift the target date.
Why All Cycles? Resolution SLAs track the full lifecycle including any re-openings. All Cycles sums active time across every cycle (open → resolved → reopened → resolved again), giving a complete picture of resolution effort.
Configure the Start condition:
Configure the Pause condition (optional). Select OR as the operator and add:
The SLA clock pauses whenever the work item enters a waiting state and resumes automatically when the status changes away from it.
Configure the End condition:
Pause conditions are optional but strongly recommended for customer-facing workflows. Without them, time spent in “Waiting for customer” counts against your team’s SLA - even when the customer hasn’t responded. Use + Add condition to add multiple pause statuses.
In the Notifications section, add up to 3 notifications per SLA:
Use placeholders in notification messages:
{{slaName}} - SLA name{{issueKey}} - Jira issue key{{issueSummary}} - issue summary{{remainingTime}} - time remaining (duration goals){{targetDate}} - deadline date (business days / date goals)In the Visibility section, configure the following options:
You now have a complete matrix of Time to Resolution SLAs, each targeting a specific priority and work item type combination. The SLA clock automatically pauses when waiting for customer input, and notifications alert the team before and at the breach threshold. All SLAs are managed from a single centralized dashboard.
