Setting up SLAs
Good service is what keeps customers coming back and a key ingredient of good service is responsiveness.
With Jira Service Management, you can keep your team on track by setting goals for how quickly you manage customer issues. If these goals are set by your customer contracts, you might know them as Service Level Agreements, or SLAs.
SLAs track the progress of things like:
- Respond to all requests within 2 hours.
- Resolve high-priority requests within 24 hours.
How SLAs look
To see how SLAs are displayed in the agent view and customer portal in different scenarios, see How teams see SLAs.
How to set SLAs
Your Jira admin or project admin can set SLAs in Project settings > SLAs.
When you set an SLA, you select three things:
- Who can view your SLA: only agents or also customers on the customer portal
- A time metric, which defines how and when time will be measured
- A goal, which defines the target to be met
Select who can view your SLA
You need a Data Center license to use this feature.
By default, SLAs are visible only for agents. You can select to display each SLA individually also for customers on the customer portal. Customers will see the status of your SLA and its time metric, but they won't see the goal itself (for example, within 5d).
Set a time metric
The time metric works like a stopwatch, tracking the time between two points in an issue's lifecycle. For example, you might start time when an issue is created, pause time while you wait for the customer to respond, and stop time when the issue is resolved.
Jira Service Management has pre-configured time metrics to cover the most common IT requirements, but you can modify these or create your own as needed.
To create a new metric, from your service desk project sidebar, select Project settings > SLAs > Create SLA and fill in the following conditions:
| Condition | Description |
|---|---|
| Name | This name (for example Time to resolution) will appear to agents in the SLAs section of issues. Agents should be able to read the name and know what they’re being measured on. You can't change the name of an SLA metric after you've saved it. |
| Start | Time starts being counted against the SLA when any of these occur (for example, Issue Created). |
| Pause on | Time doesn't get counted against the SLA when at least one of these conditions apply to the issue (for example, Status: Waiting for Customer). |
| Stop | Time stops being counted against the SLA when any of these occur (for example, Resolution: Set). |
You can set multiple conditions for the start, stop, and pause time. Here's an example of the conditions set for the Time to resolution SLA.
Check out Example: creating an SLA with multiple cycles to learn how to create a more complex SLA by starting and stopping the time counter throughout the workflow.
Set a goal
In the Goals section of the SLA metric, select the type of issue you want to track (Issues), how quickly you want to resolve it (Goal), and your team’s working hours (Calendar).
Here are some examples of goals you might set:
- Resolve blocker issues within 24 hours.
- Resolve blocker issues created by the Build Engineering team within 12 hours.
- Resolve blocker issues created by the Accounting team within 36 hours.
In the New SLA or Edit SLA screen, fill out the following fields to define a goal:
| Field | Description |
|---|---|
| Issues | You can enter specific issue criteria using Jira Query Language (JQL). Base goals on criteria that remain relatively constant throughout an issue's lifecycle (for example, an issue's priority rather than its workflow status). |
| Goal | This is where you specify the target time for the SLA conditions you previously set. When specifying SLA goals that use a fraction of an hour, write the time as Xh Ym (for example, 3h 30m). You can write SLA goals as hours and minutes, but not days. |
| Calendar | The calendar allows you to specify working hours when time can be counted against SLAs. |
You can drag goals in order of importance. An issue is tracked against the first goal criteria it matches on the list:
Set your working hours
Jira Service Management lets you create calendars that match the working hours of your team including lunch breaks, holidays, and weekends. You can then assign that calendar to an SLA, so the clock stops when your team are away.
Read Create and edit SLA calendars to learn how to do this.
SLA calendars are unique to each service project. See Example: Creating a basic SLA for an example of setting up an SLA that uses a 9-5 working day SLA calendar.
Configure your SLA settings
As a Jira administrator, you can manage permissions, formatting, and other SLA settings.
To configure your SLAs:
Go to Administration > Applications.
Select SLA configuration.
3. Find the section you want to manage.
4. Select Configure.
Clean up SLA debug log events
Whenever a Jira Service Management issue event is triggered or an SLA is created or deleted, Jira Service Management updates the corresponding SLAs. The SLA debug log feature creates an entry in the database (AO_54307E_SLAAUDITLOG and AO_54307E_SLAAUDITLOGDATA tables) to reflect that change.
As a Jira administrator, you can decide how you want the SLA debug log to be cleaned up. You can also select how often the events will be deleted from the database.
Configure thread processing
To increase the performance of Jira Service Management, we run SLA calculations in background tasks. A thread, in this context, executes those tasks, in parallel with other threads.
You can configure the processing method as well as the thread count for your SLA calculations.
Processing method | Description |
|---|---|
Multi-threaded serialized processing (Number of threads is configurable) | We recommend using this processing method. Introduced in version 4.21.0, this new processing method is self-healing, more cluster-efficient, and more reliable, specifically when Jira is running in a multi-node cluster mode. This method allows any Jira node to process any of the stored events. Unlike the in-memory processing mode, application restarts don't affect SLA processing with this method. Even if you only have one node in your cluster, SLA calculations will resume from the place they were interrupted should any interruption happen. It uses historical event data stored in the database to calculate SLAs in the order the events arrived for an issue. The thread pool in this method is configurable in the range of 1-20 threads. |
Multi-threaded in-memory processing (Number of threads is configurable) | This method is considered a legacy processing mode. The thread pool here is configurable in the same way as in the serialized processing method—in the range of 1-20 threads. In this mode, all processed events are bound to the node they had happened on. When the application stops on one node, all unprocessed events are lost, and not included in the SLA history until it's manually reconstructed (for versions before 5.0) or until another event happens on the same issue (from version 5.0). |
No background processing (Number of threads isn't configurable) | In this method, all processing is done in the request thread, locking the response (user feedback) until the SLA calculation is finished. If you select this processing mode, you might experience significant decrease in the perceived performance of actions like issue creation, comment creation, or issue transition. |
SLA calculations result in querying the database to fetch information. Our databases use connection pools to limit simultaneous active connections to it. In case of no background processing, we don’t control the pool count as it works on HTTP threads. This may lead to a fast database connection pool exhaustion under load. Learn more about database connections
Configure the SLA thread count
If you select the multi-threaded serialized or the multi-threaded in-memory processing method, you can configure the thread pool count for your SLA calculations in the range of 1-20. Thread count values are synchronized across all nodes without restarting the processors.
The default number of SLA threads per node is set to 5. However, in case the SLA calculations aren’t keeping up with issue updates, we suggest using the recommended multi-threaded serialized processing method and bumping up the SLA thread count in small increments while observing the system response.
Updating SLAs
When you change the configuration of existing SLAs, we follow these rules:
We don’t recalculate, or touch in any way, cycles that have already been completed. A cycle is completed when a request fulfills the Start and Stop conditions (depending on your configuration and events, another cycle of the same SLA might then be started).
We recalculate ongoing SLAs so they measure against your new configuration and metrics.
It might happen that ongoing SLAs will be completed or discarded entirely after changing the configuration. This can happen if you remove the previous Start or Stop conditions or change them to something else, which will trigger the completion. As mentioned earlier, ongoing SLAs will be recalculated to use your new configuration.
Recalculate your SLAs for a single issue
Occasionally, issue events that should trigger a change to an SLA value are missed or interpreted incorrectly resulting in an incorrect SLA value showing in the queues or the issue view. Usually, SLA calculations will catch up to missed events and correct the values, but if they don’t, you can recalculate the SLAs for an issue in the issue view.
To recalculate your SLAs for an issue:
Go the issue view.
From the SLAs section select the more actions menu
> Recalculate all SLAs.
Select Recalculate.
Best practice SLA usage
- Try to select an Assignee who's not the Reporter of an issue. If you assign the same user, your SLA might work incorrectly.
- If issue data changes in such a way that the goals for the issue change (for example, the priority changes from Critical to Blocker), the time against the previous goal will be tracked against the new goal, for open issues only.
For example, if the Support team spent an hour on a Critical issue, when the issue is escalated to Blocker, the hour still counts against the new goal, even if it causes the SLA to be breached. - If you're using filters in your service project to track SLA data, specifically priorities, make sure these filters include all the priorities defined in the associated priority scheme. See Associating priorities with projects for more details.
- We do not recommend setting up a goal to be dependent on a different SLA.