Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

A fresh look at SLAs in Jira Service Management


We have just deployed an update to this feature that lets project admins choose which display format is best for each SLA in this project. Learn more below.

Starting in December we are rolling out a notable change to the way SLA expiry is displayed in Jira Service Management.

SLAs: Old format vs New format

The new format presents the time until expiry as a due date, as opposed to a countdown timer of the hours and minutes until expiry. The hover state in the new format displays the original behaviour.

The new hover state will show a relative date for Yesterday, Today, and Tomorrow, and for all other times, it will show the date. Learn more.

Choosing the right format for you

Screen Shot 2022-06-07 at 3.47.21 pm.png

Based on your feedback we know that different formats work for different SLAs/projects. When creating/editing a SLA, select the display format that works for that SLA. You can change the format whenever you like, but keep in mind each time an SLA is saved issue goals will be recalculated.


Why we think you’ll like the new format?

Computers work in numbers, no matter how many hours and minutes are remaining, they immediately know how to translate it into a due date. For humans on the other hand (no matter how good you are at maths) it is not as easy.

Removing ambiguity

Let’s look at some examples:

If there are 2 hours remaining that is easy… right? But what if it's the end of the day? Then actually it won't expire until sometime tomorrow morning. What if the calendar excludes tomorrow, then it might not expire until next week.

For SLAs longer than 24 hours, this gets even more complicated. If there are 37 hours remaining, when will the SLA actually expire? Which calendar is it using?!? 😵‍💫

As you can see, there is no easy way to know exactly when an SLA will expire, we want to help you avoid the algebra and get back to delivering value to your customers.


We would love to hear what you think about this feature. Please leave a comment and if you are ok with us getting in touch for a discussion.


Dirk Ronsmans Community Leader Dec 08, 2021

Normally I'm not a fan of those "yesterday"  type of date notations and having to hover, but this one actually makes sense!

I never really considered the fact that you couldn't see the calendar as a bottleneck but I totally get that.. 

Looks good!

Like # people like this

@Benjamin Paton  Very interesting, thank you for informing us. I want to ask you, but have you solved the problem that if you create a SLA, it is not possible to rename it, unless you delete the whole thing and do it all over again?

@Calogero Kalos Bonasia thanks for your feedback. Renaming SLA not fixed yet, but is definitely on the backlog.

This is great news.  I sort of wish I was back on my last companies' service team to see this in action and pass along to customers.  

I prefer the old method. Please provide the ability to choose the old way as it is more applicable to our needs. Having to hover over every entry is not an improvement for me.

Like # people like this

How are the times now exported when I do reporting to show how long before or after the SLA goal the reply was sent?


What would be best for reporting is the actual time in hours/minutes that it took to send the reply (a count-up timer only). Is this feature planned anywhere?

How to revert old time format? For us it is so very uncomfortable now. 
It causes a lot of extra work :( 

Like # people like this
Dirk Ronsmans Community Leader Dec 27, 2021

@Péter Péli can you elaborate how exactly this causes extra work?


I can actually explain why this is bothering us.

Our bigger teams usually prioritize tasks based on the remaining time.

You make the assumption that it is easier for the computer to calculate the due time thus better for the user but you tell me what is easier to read - Today 10:36 or 34m. 

You also conclude that the new format is better for the end-user (customer) but the changes ignore teams that communicate with customers in languages that don't support translation in Jira plus teams that communicate with the customers mostly through e-mail (we don't oblige our customer to enter the ticket. they reply through e-mail).

I am unsure how this improvement was reviewed but I suggest giving us a menu where we can choose how it is displayed - for us and for the customers.

Best wishes,
Nikolay Petrov

Like # people like this


it end of the month, definitely more than "2 weeks" and on my Jira Cloud Service Management Project o still see "-7,617h 18m". Should i do something more or change any setting?

Second, do you have plans for making as a setting - old one or new one to choose for?

Happy New Year!


@Dirk Ronsmans We're operating a public bike sharing system.
JIRA performs KPI and SLA calculations.
We’ve created a module in it to help redistribute bikes.
If a bicycle is not available at a station for a certain period of time, the monitoring system will open a ticket in JIRA. There are several types of grace periods, which vary from station to station.
The queue in the image shows that SLA violating notifications are sorted in descending order of time remaining. Due to the specifics of our city, a dispatcher directs logistics colleagues from where to where they should move the bikes, thus resolving the SLA violation.
Hundreds of these tickets can open and close daily without intervention. We work 0-24 every day.
Now, since the update, the dispatcher has to hover the mouse over the stations one by one to see how much time is left and make a decision accordingly. This causes difficulty and extra work and degrades the user experience. All of our users have complained since the introduction and we don’t know what answer to give them what to expect.jira.PNG

Like # people like this

Hello all, 

Thank you for your feedback over the holiday period. I am back in the office as of today, let me provide some responses. 

@Jerry Siskind @Péter Péli @Hubert Bedyk we currently do not have plans to make it a setting, but we are evaluating feedback. If it were a setting, from your perspective how would you configure it? (e.g. per site, project, or SLA).

@Steph Bannister reporting remains the same. Behind the scenes an SLA is still a countdown of hours and minutes. We have no plans to change it to be a round-up, but this is something that can be calculated for reporting purposes.

@Hubert Bedyk if you still have not seen the change it will arrive for you this week, the final phase of the rollout is scheduled for 6 January.

@Péter Péli @Nikolay Petrov thank you for taking the time to provide extended feedback.



@Benjamin Paton Thanks for this reassurance!


Like Benjamin Paton likes this

@Benjamin Paton IMO the best way is settings per site as default for all projects and setting in every project if you need other way in a particular project. And as simple as it can be - for example one option with two values: old format - new format.

Like Benjamin Paton likes this

@Benjamin Paton 

Project settings or user profile setting


Anyway, I'm done with a workaround

I created a customfield (for old sla remaining time)  and checked the API response:


I use Automation to read the API response and modify the customfield
example smartvalue: {{fields.customfield_10106.ongoingCycle.remainingTime.friendly}}



I'll show the result in the queue.


Unfortunately not a very cpu time friendly method, but suddenly we couldn’t figure out a better one.

The purpose of this original ticket request was to give admins the ability to choose the display format that best suited their JSM project, and how their teams wanted to view SLA's. We did not accomplish this here.

Now many users are stuck having to hovering each ticket SLA to see the time remaining. There needs to be an update at the project level immediately that allows users to choose their SLA display format in the Old version. Please give us options and don't force a path that's not natural. - Thanks Chris

Like # people like this

@Hubert Bedyk thanks for the feedback.

@Péter Péli very impressive workaround.

@Chris Hansen we are always trying balance capability and complexity. Can you tell me more about why the new format does not work for your team?

Hi @Benjamin Paton - No problem. I know how it can be. I do think adding options in the project settings for SLA's w/ old & new formats would have made us happy.

Here are a few reasons why the new format doesn't work well for me and my team. 

  • It requires our teams using JSM to either do math in their head or hover over each ticket to see how much time is remaining.
  • When trying to not only met the SLA, but beat it looking at a date when the ticket needs to be completed by doesn't give quick and easy visibility into how long a ticket has been on the service desks teams plate for. Sure you could add the created date column to a queue, but again then you're trying to figure things out. 
  • When looking at my team's queues (e.g. avg. response time) to tickets I can't quickly see how long it took them to respond to certain issues w/o hovering over each SLA. Whereas before I could quickly see the state of all tickets and how quickly we responded to our customers.
  • We also noticed that the column for SLA is sometimes hidden in our queues making it sometimes hard to read the date timestamp in it's entirety. 

See here: 2022-01-06_19-55-12.png

Like # people like this

Thanks for the feedback @Chris Hansen. We are working on an update to increase the minimum column width for the SLAs to ensure they are displayed more effectively.

Good Morning All, 

Can I just check that I am reading this correct, please?

Resolution SLA due (or expired)  04/11/2021  @ 11:56

Actual Resolution time 07/01/2022 @ 2:22pm

Total Breached time : -332h 12M



Dirk Ronsmans Community Leader Jan 11, 2022

@sally usherwood that sounds right to me.

Like sally usherwood likes this

That excellent, Thanks @Dirk Ronsmans  :) 

Honestly, this feature seems like a step backwards for me. The countdown timer helps my team prioritise tickets and decide which ones to do first.

It's quicker and more natural to look at a countdown timer than the way it is now.

Please provide an option for your customers to choose which SLA format they want!

Like # people like this

Please revert or provide an option to customize.

May I ask why didn't you set the new format in the tooltip as an improvement and leave existing format in the main field as it was?

Before I knew how much time is left exactly on a task. Now it shows me an abstract point in time in a different timezone!


Before: 1 hr 45 minutes left

After 30 Nov 11:45 AM

Now I have to subtract 11:45 from current time to know whether I have enough time left or not! In addition I have to calculate for the timzeone offset.

This scenario proves your argument (but in reverse of what you meant - this time humans must convert back from due date into time left):

Computers work in numbers, no matter how many hours and minutes are remaining, they immediately know how to translate it into a due date. For humans on the other hand (no matter how good you are at maths) it is not as easy.

Also, it is now very hard to take screenshots. I cannot use the snipping tool as the tooltip disappears when I try to select a screen area.

Like # people like this

Hi @Benjamin Paton

we are Atlassian Solution Partner but experience a lot of unsatisfied customers. The main problem they have:

In the old view they did see the time differene between the SLA Date and the current. This is pretty important for customers. Currently they see only it's breached, but there's no vissible difference between 1hour breached and 100hours breached, only by hover.

This is definitely a big pain we see her for Atlassian customers and disturbs their daily business. There's a strong need to even have the option to  change the format back to the old format (better: to the former Server Format inclund months, weeks and so on, not only hours).

Currently we see even Cloud Migration projects running in a stop because of this. It's a situation we want to impede I guess.

Best Hannes

Like # people like this


Log in or Sign up to comment
Community showcase
Published in Jira Service Management

An unofficial way to monitor a JSM mail handler for errors

...eturns true if any content is returned for the s...

665 views 3 20
Read article

Atlassian Community Events