IT Service Managers and Support Team Leads responsible for meeting response time commitments across different priority levels - especially teams managing Incidents where a Blocker requires a response in minutes, not hours.
Your team handles hundreds of tickets daily. A critical server outage and a “can’t change my avatar” request both land in the same queue - but they require vastly different response speeds. Without priority-based SLA tracking, your team treats everything the same, and your most important customers wait too long while trivial issues get attention first.
Create a single SLA with multiple goals, each targeting a specific priority level using JQL. This approach gives you precise control - you can combine priority with any other Jira field in one query, all within a single SLA configuration.
The SLA clock only ticks during defined working hours. Before configuring the SLA, make sure you have an appropriate calendar.
You can reuse the same calendar across all goals within this SLA. You cannot delete a calendar that is already used in an active SLA.
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 First ResponseGoals are where you define the target time and the JQL filter that controls which issues the goal applies to. Add one goal for each priority level.
In the Goals section, click Add Goal and fill in the following for the first goal (Blocker):
Goal name: Blocker - 1h
Calendar: select the calendar created in Step 1.
Goal type: Duration
Target time: 1 hour
JQL filter:
priority = Highest
JQL lets you combine priority with any other Jira field. For example: priority = Highest AND issuetype = Incident AND project = HELPDESK
Click Add Goal again and repeat for each remaining priority level:
| Goal name | JQL filter | Target time |
|---|---|---|
| Blocker - 1h | priority = Highest |
1 hour |
| Critical - 4h | priority = High |
4 hours |
| Major - 8h | priority = Medium |
8 hours |
| Minor - 24h | priority = Low |
24 hours |
All goals share the same start, pause, and end conditions defined in Steps 4–5. Each goal independently evaluates which issues it applies to based on its own JQL filter.
Why First Cycle? For Time to First Response, only the first response matters. First Cycle captures the initial response and ignores any subsequent activity if a ticket is reopened.
Configure the Start condition:
The SLA clock starts the moment a new issue is created.
Configure the End condition. Select OR as the operator and add two conditions:
The SLA stops when either the assignee starts work (status change) or posts the first public response (comment).
Use + Add condition to add multiple conditions. Select AND when all conditions must be met simultaneously, or OR when any one condition is sufficient.
In the Notifications section, add up to 3 notifications. For TTFR, a single warning before breach is typically sufficient:
Available placeholders: {{slaName}}, {{issueKey}}, {{issueSummary}}, {{remainingTime}}. Keep the original formatting - otherwise placeholders won’t work.
For each goal you can add a different calendar.
In the Visibility section, configure the following options:
Your SLA is active in the selected projects. Every new issue is automatically evaluated against each goal’s JQL filter and tracked against the matching target. Agents see a color-coded countdown panel directly in the issue view; customers (if enabled) see the expected response time in the portal.
