Setting up SLAs

Keep your team on track by setting goals for how quickly you respond to and resolve tickets. If these goals are set by your customer contracts, you might know them as Service-Level Agreements, or SLAs.
SLAs might track goals like:

  • Resolve high-priority requests within 24-hours

  • Respond to all requests within 2 hours

Once you set SLAs, you can view them in queues and on issues. You can also get alerts for SLAs that are about to breach, and create reports to track SLAs over time.

On this page:

Set SLAs

Service desk project administrators can set SLAs in Project settings > SLAs.
When you set an SLA, you choose two things:

  • A goal.

  • How you count time to the goal.

Name the SLA

You won't be able to change the name, so make sure it clearly explains your SLA and what it measures.

Set a goal

In the Goals section, choose the type of issue you want to track, how quickly you want to resolve it (the goal), and your 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, and resolve blocker issues created by the Accounting team within 36 hours

It's a good idea to base goals on criteria that don't change throughout the issue's lifecycle. For example, don't create goals based on issue status.

Here's how to set a goal:

  1. Use JQL to define the Issues you want to track.

  2. Enter the Goal in hours and minutes. For example, 30m, 1h15m, 48h30m, or 72h.

  3. Choose which work Calendar to follow.

Here's an example of a goal to resolve issues in different time frames for different customers. In this example, you provide 24/7 support for Gringotts Bank, and 9-5 support for Stark Industries:

Note that the SLA reads goals as 'or' rather than 'and', which means their order matters. When an issue matches the Start condition, the SLA starts counting time on the first goal that matches the issue. If an issue matches more than one goal, the SLA tracks the first one in the list.

  • You can create 30 SLA goals per project. If you need more, see if you can combine goals, or delete ones you don't use anymore.
  • If the same user is both the reporter and the assignee on an issue, then the SLA might not track it correctly. 

Set a time metric

The time metric is like a stopwatch that starts and stops the countdown to your SLA goal. For example, you might pause time while you wait for the customer to respond, and stop time when the issue is resolved. The calendar counts time according to your team's schedule. For example, you might pause it outside of business hours, or during holidays.
You can set multiple conditions for the start, stop, and pause time. For example, the goal of this SLA is to respond to Access issues within two hours. This includes responding when the issue is created, as well as when the customer updates the issue:

Start, Stop, and Pause conditions are read as 'or', not 'and'. If you add two Start conditions, the SLA will measure time when an issue meets either of these conditions.

Set your working hours (optional)

By default, SLA clocks run 24/7. If you want to exclude lunch breaks, holidays, or weekends, go to SLAs > Calendars to set your working hours.
For example, you could tweak the Sample 9-5 Calendar to add a 1-hour lunch break that doesn't count toward the SLA. Just delete the 09:00-17:00 timeframe and add a timeframe for before lunch (08:00-12:00) and after lunch (13:00-17:00). Here's what it looks like:

Update SLAs

What happens if SLAs change

If you edit an SLA, Jira Service Desk recalculates time for all issues in the project that have ongoing SLA cycles. To ensure your reports are accurate, Jira Service Desk doesn’t recalculate time for completed SLA cycles.


For example, you might have a goal to resolve all Blocker issues in 6 hours. If you change the goal to 4 hours:

  • Blocker issues that have been open for more than 4 hours are marked as breached.
  • Blocker issues that were resolved in under 6 hours have still met the SLA.

What happens if issues change

You might update an issue in a way that changes which SLA it's measured against. If you do this, the SLA clock doesn't restart, but adds any elapsed time to the new goal. In some cases, this might breach the SLA.

For example, imagine you have a goal to resolve Critical issues in 5 hours, and Blocker issues in 3 hours. A Critical issue has been open for 4 hours, and someone changes the priority to Blocker. Because issue is now a Blocker issue with 4 hours on the clock, the SLA is breached.

Manage SLA data

If you create a new name for an SLA metric, the name - not the metric - is copied to all service desk projects on your Jira site and stored as a custom field. For example, if you create a metric called Time to resolution by priority, other service desk projects can create metrics with that name:

Jira administrators can choose who has permission to create new SLA metric names. You can also view the number of fields being used, and clean up unused fields. To manage these settings:

  1. Choose  > Settings > Applications.

  2. Under Jira Service Desk, select Configuration.
  3. In the SLA metric names section, you can change who can create new SLA metric names. If there are SLA custom fields not in use, click Clean up to delete them.
Last modified on Aug 15, 2018

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.