How teams see SLAs
Support teams rely on SLAs to plan and track their time against issues.
Jira Service Desk shows SLAs in a human readable time, instead of only hours and minutes. That way, Agents don't spend precious time working out what 78:00 means in days.
On this page:
Your team sees a read-only version of the SLA tab, so they know how the SLA is configured. In the issue view, the SLAs section lists more information about the SLA that the issue is being measured against:
The times shown by the SLA reflect the calendar settings for that SLA. Hovering over an SLA will give you information about the specific metrics of an SLA.
Units of time
The following units represent time in an SLA:
|Minutes||m (min if single unit)|
Only 1 or 2 units, at a time, are displayed for simplicity, with a combination of the following:
How the clock works
Jira Service Desk calculates minutes, hours, days and weeks by using the working hours set in the associated calendar. It calculates a month and a year by using approximations of 4 weeks and 12 months respectively.
Remaining time is calculated by looking at the time from now until due, taking into account any pauses.
For example, Request A has an SLA goal time of 16 hours, with a start time of 11:00 on Monday, and working hours as follows:
- Monday 09:00-17:00
- Tuesday 09:00-16:00
- Wednesday not working
- Thursday 08:00-17:00
- Friday not working
- Saturday not working
- Sunday not working
How to read the diagrams:
Jira Service Desk calculates goal time similar to remaining time, but now is set to start of goal. Goal time doesn't take any future pauses into account.
Regardless of the current time, the goal time is always calculated from the start time.
In some situations, your Agents might see time displayed as something like 1d 26h. This happens when an SLA starts and stops for a period of less than a day (for example, 7 hours in an 8 hour working day).
All partial days are accumulated as hours and minutes, but not converted to 1 day, because the definition of a day will change depending on the working hours set in the calendar.
For example, Request B has a goal time of 24 hours, with a start time of 10:00 on Monday, and working hours displayed in the diagram below. The SLA goal is 1d 15h and the SLA is due at 16:00 on Wednesday.
It works like this:
- From 10:00-18:00 on Monday is not a complete working day (according to the calendar). Total = 8 hours.
- From 09:00-18:00 on Tuesday is a complete working day (according to the calendar). Total = 1 day.
- From 09:00-16:00 on Wednesday (SLA due time) is not a complete working day (according to the calendar). Total = 7 hours.
8 hours + 1 day + 7 hours = 1d 15h
The SLA tracker uses colors to indicate the urgency of an SLA for an issue, based on the time remaining.
|The SLA clock is ticking.|
|The SLA has less than 30 minutes before breaching.|
|The SLA has breached the target. The amount of time past the goal is shown as a negative number.|
|The SLA has been paused or is currently outside of working hours.|
A completed SLA displays the time remaining when the SLA was completed (or the amount of time breached) and an icon to indicate whether the SLA was completed successfully or unsuccessfully.
|The SLA completed successfully.|
|The SLA breached its target.|
Multiple SLA targets
If the issue meets the criteria for multiple SLAs, trackers for each SLA will appear. In addition, if the SLA has had multiple cycles, you can hover over the symbols for more details on how the SLA was met for that particular cycle. For example, in an SLA that is measured based on when an issue is Waiting for support, you can see whether the SLA was met each time the issue started Waiting for support.
When you view a list of issues (in a queue or elsewhere), you can sort them by their SLA remaining times. Ongoing issues are listed first, with the shortest time remaining at the beginning of the list. Completed issues are ranked last, but aren't sorted by the remaining time.