SLAs in JIRA Service Desk - Valiantys - Atlassian Platinum Partner

SLAs in JIRA Service Desk

SLAs explained

Some service contracts involve agreements on response times, or SLAs (Service Level Agreements), to solve requests. Teams and customers need this information for each request in order to better handle priorities and guarantee optimal service quality. But that’s not all – SLAs can also help identify areas for improvement.

The good news is that JIRA Service Desk has got you covered. Why? Because it allows you to set SLAs per project, and display them on your tickets in the form of a little timer counting down the remaining time.



  1. If the SLA is defined at 1 hour, for example, then the icon colour will be grey when they are 30 minutes left, and change to orange when only 15 minutes remain.
  2. It’s possible to display as many SLAs as you want on the ticket (yeah, as many as you want!)

Before I tell you more about the set up, let’s have a look at different views, and how SLAs display on them.

View on the request


View on the portal

Natively, JIRA Service Desk does not allow you to see SLAs on the portal. With Valiantys IT Service Management solutions however, you can preview SLAs directly from the customer portal. Awesome, isn’t it? To obtain this render, you’ll need the additional component called Extension.


Setting up an SLA

Now, let’s talk about the serious stuff – SLA settings.

An SLA first possesses a nam, which will be displayed on the JIRA request. It’s important to pick its name carefully so that it’s accurate and easy to understand for everyone involved.

set1An SLA is calculated between two events. It can also be paused when the request enters a particular state.


Events are not configurable. Triggering and stopping events can be:

  • Entering a state in the workflow
  • Filling or clearing the Resolution field
  • Unassigning a ticket
  • Assigning a ticket – whether the request was previously unassigned or assigned to someone else
  • Adding a comment for the customer
  • The addition of a comment by the customer


Events that can pause an SLA are:

  • Entering a certain state in the workflow
  • Filling or clearing the Resolution field
  • Unassigning a ticket
  • Assigning a ticket (only when the request was previously unassigned)

It is then possible to define as many SLAs as you wish. The execution criteria are defined in JQL and can thus be based on native or custom JIRA fields values. Usually SLAs are configured on a specific request type and on a specific priority.


The amount of time during which the SLA is running is defined by the calendar. You can create as many as you need.


Remember to give it an easy-to-understand name so that all of your agents and customers get it instantly when they see the icon calendar on the SLA displayed on the JIRA ticket.


Specific cases

Change in a criteria linked to the SLA

If a change occurs on a ticket’s criteria which is also an SLA criteria (for example, priority), then the SLA will be actualised:

was-high + The priority was high…

now-low + … and is now low

SLAs measuring a loop

If the SLA is configured to measure the time between two states, for example ‘Open’ and ‘Waiting for customer feedback’, it can sometimes be measured several times. Indeed, this transition can occur several times on the same request.

The SLA is designed to handle multiple measurements. A little icon that you can run your mouse over allows you to see the different times captured.

Reporting on SLAs

SLAs are like any other fields, and can be integrated to your searches.

In your requests:


And in your queues:


JQL queries

In search, you can find specific instructions regarding SLAs and apply them to any SLAs you are creating (e.g. “Time to resolution” = paused().

Here’s a list of the commands you can run:

running(): find JIRA tickets on which the chosen SLA is currently running.

paused(): find JIRA tickets on which the chosen SLA is paused.

completed(): find JIRA tickets on which the chosen SLA has been reached (the terminating event has happened), whether it has been respected or not.

breached(): find JIRA tickets on which the chosen SLA has not been respected, whether the SLA is still running or terminated. If the SLA has been restarted several times (specific cases seen before) , only the JIRA tickets in which the SLA was breached in the last SLA cycle will be displayed.

everBreached(): find JIRA tickets on which the chosen SLA has always been breached (same as  breached() but on all “JIRA cycles”).

elapsed(« <Time> »): find JIRA tickets on which the chosen SLA has been running for X time, for example: Time to resolution < elapsed(« 2h »)

remaining(« <Time> »): find JIRA tickets on which the remaining time for the chosen SLA is of X time, for example:  Time to resolution < remaining(« 20m »)

So there you have it – everything you need to know about SLAs! Any questions or comments, leave them below and I’ll get back to you.

Cutted Triangle

Subscribe to the Valiantys Newsletter

Registered request ! Subscribing... This is not an email An error occured

In accordance with our privacy policy, we are committed to respecting your personal data.

Contact us

Our Atlassian certified consultants will be happy to answer you.

Join us

We're building the next dream team - Are you in?

Follow us

We use cookies for the operation of our website. This is to improve its use, to personalize your experience, and to compile visitor statistics. By continuing to use this site, you consent to this policy. You can manage the settings and choose whether or not to accept certain cookies whilst browsing. For more information, see our privacy policy. Our privacy policy

Privacy settings

In order to facilitate your navigation and to provide you with the best possible service, we use cookies to improve the site to the needs of our visitors, particularly according to the number of visitors. For more information, please read our privacy policy. Our privacy policy


Google reCAPTCHA is a system designed to distinguish humans from computers, so that bots are unable to maliciously fill out forms on behalf of a human being.


Used to send data to Google Analytics about the visitor's device and behavior. Tracks the visitor across devices and marketing channels. Used by the social sharing platform AddThis to store the user's usage history of the AddThis sharing widget. Registers a unique ID that is used to generate statistical data on how the visitor uses the website.


Targeting Cookies: Targeting cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant advertising on other sites. They are based on uniquely identifying your browser and internet device. You can turn off the use of cookies for targeted advertising here. When the button is green, targeted cookies are on. When the button is red, targeting cookies have been turned off.

Social Media Cookies: These cookies are set by a range of social media services that we have added to the site to enable you to share our content with your friends and networks. They are capable of tracking your browser across other sites and building up a profile of your interests. This may impact the content and messages you see on other websites you visit. If you do not allow these cookies you may not be able to use or see these sharing tools.