What is a proper approach for SLA in Jira Cloud

Question

We use Jira SLA feature for the Time to Resolution targets in the JSM projects. We are wondering whether the following SLA adjustment logic is feasible to implement in Jira? At the same time, we're curious how other companies addressed similar concern.

Problem:
It happens that a priority of an incident is elevated. What is currently happening in such situations, the SLAs (both time to resolution and time to first response) often immediately breach, due to shorter time associated with higher priority (usually 8h → 4h TtR and 30m → 15m TtFr).

It doesn't leave any space for engineers to react and meet targets.
Reporting on such cases is very problematic.

Our vision on how to address such scenario:

Logic to apply when issue priority changes:
• If the remaining SLA time is less than or equal to the target associated with the new priority → continue the current SLA without changes.
• If the remaining SLA time is greater than the new priority's SLA target → stop the current SLA and start a new one with the updated, shorter target.

Questions:
Can this be achieved with native Jira functionality? Does best practises/ITSM/experince provides other solutions for such cases?

Thanks in advance or any help:)

Alina Kurinna _SaaSJet_ · Answer

Hi @Marek Bujak - YTS

Great question — what you’ve described is a very realistic scenario in ITSM environments, and it’s true that Jira’s native SLA engine doesn’t currently support dynamic SLA recalculations based on changing priorities in the way you’ve outlined.

The challenge:
In Jira, when priority increases mid-lifecycle, the SLA does not recalculate or re-adjust gracefully, which often leads to instant SLA breaches (e.g., when TTR changes from 8h to 4h).

So, if you're open to using Atlassian Marketplace apps, I recommend trying SLA Time and Report, developed by my team. It’s specifically built to support dynamic and conditional SLA logic, including the scenario you've described.

With SLA Time and Report, you can:

* Reset SLAs automatically when a specific field changes (e.g., Priority), using our Reset SLA feature
* Apply custom SLA goals based on issue fields like Priority, Severity, etc.
* Define start/pause/stop conditions tied to field changes or statuses
* Report clearly on SLA breaches and performance, segmented by assignee, priority change, or other criteria

You could configure your scenario as follows:

* If Priority changes and new target is stricter → reset SLA with updated goal
* If current time left is already within new tighter goal → continue SLA without reset
(This logic can be adapted using conditions + reset triggers in the app)

I hope I was able to help. If you have any further questions, feel free to reach out!

Regards!

ileads com · Answer

Problem

When an issue's priority increases, Jira recalculates SLA targets (e.g. from 8h to 4h), often causing instant breaches, even if engineers were on track before.

Your Proposed Logic

If new priority SLA < remaining time → restart SLA.
If not → continue current SLA.
This is fair, but not natively possible in Jira Cloud.

Workarounds

* Automation + Custom Fields
Log time at priority change and flag for exception reporting.

* Multiple SLA Rules per Priority
Trigger appropriate SLA via automation; deactivate old one.

* Marketplace Apps (Best Option)
Tools like Time to SLA allow SLA restarts, dynamic logic, and better reporting.

Best Practices

* Limit mid-issue priority changes.

* Use labels to flag SLA exceptions.

* Report based on initial priority SLA.

Let me know if you want help setting up any of these.