Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


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

Hi Team,


I have one doubt regarding the SLA running. Some issues we might need more time to resolve (Depending on availability). In this situation, I don't want to break my SLA. How to I stop my SLA? Is there any automation I can use for this?

1 answer

1 accepted

2 votes
Answer accepted
Dirk Ronsmans
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Mar 30, 2023

hi @Rakesh Gokuldas ,

Aside from the fact that having SLA exceptions isn't really a correct practice you could work around it.

personally i would think you can actually put a business rule as to why this issue needs more time to resolve so they become a different category. You can do this using a flag (custom field) on the issue or a different state.

You simply need to classify the issues differently then so another "goal" is used or even us a different status to "pause" the SLA.

But like I said, availability on your end should not impact the SLA agreement with your customer. If you don't have the resources all the time, your SLA should be re-negotiated or you should get the funds to get the resources to be able to fulfill your SLA. Simply pausing the SLA cause it might breach isn't a proper way of working.

If it breaches then it breaches and you should investigate why and take action towards it to either get a longer SLA (let's say on weekends/outside business hours/...) or get more resources to cover your SLA as it is.

I have a similar problem / concern with Tickets in Jira Service Management (JSM) .

We have two SLA's for Report an Incident (RAI) type tickets in this Teams Managed project.

Time to first response (TTFR)

That we need to meet  this for customers, (depending on the Customer it has different SLA's for each Pri)  these are triggered by changing the status of the ticket. If we are inside the TTFR we get a green tick if not we get a red X.

This has different times depending on the Priority of the ticket.
the one pictured is a priority 3 is 18 business hours which is calculated on the SLA of Mon-Fri 08:00 to 17:00 - which is two business days

We can then hover over the field to see some more information- happy with that.

The concern is Time to Done

which is 90h for a Priority 3  Mon-Fri 08:00 to 17:00
which equates to 10 business days. happy with that 

The time to done is paused when it is on  Pending Vendor  and some other statuses, Time to done shows 07 Jun 12:29 happy with that. 

The concern I have is the date.

The Time to done doesn't appear to be recalculated when it comes off the Status that has it on hold. The due date stays the same and isn't updated. which gives a false impression of where the ticket is.

This is a concern that I've been trying to figure out, without adding an App that I'd need to configure to get this info.

I currently run a filter that I export the data to excel, format some fields and paste into a table in Powerpoint. 

Shouldn't JSM be smart enough to be able to recalculate the Time to done  as a ticket goes in and out of being in a paused status?

We have penalties if these are not met, on the face of things it looks like we have failed but if it was to be investigated the majority of these would meet the time frames.


Time to Done Paused.png 

The ticket type does have a Due Date field  which I've been advised is a static date and manually entered - this is used  when a ticket is part of software development and is part of a patch, the due date is the when that Patch is going to be released.

I've managed to add an automation that will initially populate the Due Date depending on the priority but it is a once off and needs to be manually updated from there on in. and will also have to be calculated when a ticket goes in to hold or moved off hold status.

I've also had assistance where Custom fields have been created  in a project with an automation behind it that changes dates when it goes on and off a Status that puts the ticket on hold- I'm not 100% sure it is meaningful, so still looking at this.

Any ideas?

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events