Why SLA recalculation matters (and how to do it right in JSM)

[#1]

The calendar has changed, or a condition has been misconfigured, and boom, your SLA data is off now. Some Jira admins lose sleep over it, asking on Atlassian Community: “How do I recalculate my SLA?” or “How do I restart the SLA clock?”

This article is your easy-to-follow guide to recalculation. It will show you how to maintain accurate SLA data and what is possible in native Jira Service Management, and what’s not.

                    Something has changed in SLA. How to recalculate it?

Putting SLAs back on track

SLAs aren’t set in stone. Priorities shift, calendars change, and definitions evolve. When that happens, the original SLA values quickly lose accuracy.

Without updating, teams might struggle with things like:

• Skewed reports because of breached tickets that shouldn’t be counted.
  
  
• Compliance risks with closed issues locked to outdated rules.
  
  
• Misleading priorities when agents chase the wrong deadlines.
  
  

Recalculation ensures SLA data remains aligned with current policies. This helps keep reports, audits, and day-to-day decisions reliable.

4 common scenarios where recalculation is essential [+ solutions]

Even the best SLA setup needs adjustments. Here are the cases where recalculation makes the difference.

I) Priority changes

Potential challenge: A ticket might start as Medium with a 48-hour SLA, but later get escalated to Critical, which should only allow 4 hours. In native Jira Service Management, the SLA timer continues tracking against the old target.

What to do: Recalculate SLA timers so the issue is measured against the correct, updated goal.

Native JSM: You do not need to click anything. In that case, for active issues, the SLA in JSM automatically recalculates (but does not restart timers) on priority change. However, remember that it only works if there is a match — specific goals are assigned to specific priorities in the SLA configuration. 

When a specific request type is applied in JQL, the SLA will be automatically recalculated after the priority change.

Workarounds/ alternative solutions: 

• For recalculating closed tickets, you will need to use Marketplace apps with recalculation features such as SLA Time Management, which let you update SLA goals at any time—even retroactively for active or closed issues.
  
  

II) Calendar updates

Challenge: Your SLA was set to 24/7, but later adjusted to business hours. Tickets created before the change still calculate against the old calendar, so many appear as “breached,” even though they were resolved within working hours.

What to do: Recalculate SLAs after updating calendars or holidays so compliance reports reflect the correct working schedule and remove false breaches.

Native JSM: The calendar updates affect future tracking, but historical SLA data is not recalculated. Open issues may partially adjust, but past breaches remain unchanged.

Workarounds / alternative solutions: Use automation with the REST API or third-party apps that let you recalculate SLAs for past, active, or even closed issues.

III) Wrong SLA setup

Challenge: Sometimes, an SLA condition or goal is misconfigured during rollout — for example, measuring Time to Resolution from the wrong status. This leaves numerous issues with invalid SLA values, skewing reports, and triggering false automation.

What to do: Recalculate SLAs to clear and reapply the corrected logic, instead of trying workarounds like cloning or bulk-editing issues.

Native JSM: SLA definitions update automatically apply to new and active issues, but past issues keep their old values. 

Workarounds/alternatives: You can use SLA management apps that support one-click recalculation across active and closed issues.

In SLA Time Management, you can recalculate SLA data for selected issues (open or closed) using the Recalculation option. The scope is set in JQL. 

IV) Historical corrections

Challenge: Closed tickets may still contain outdated SLA values, which can skew compliance rates and audit reports. For instance, an old calendar made 20% of resolved tickets look overdue, even though they weren’t.

Solution: Run recalculation on historical issues before audits or quarterly reviews to ensure your SLA data matches current policies.

Workarounds / alternatives: You can use the REST API to bulk recalculate open issues, but for closed or archived issues, you will need add-ons like a Marketplace app. 

How Jira Service Management handles recalculation

Jira Service Management does not provide a built-in “Recalculate” button in its SLA configuration UI. 

The recalculation works automatically for active issues. For instance, when the SLA is active and based on priority, and the issue's priority changes, the recalculation occurs automatically. However it does not restart the timers. 

Native JSM SLA recalculation will not happen in closed and inactive issues, nor will it be applied retroactively. 

Best practices 

Recalculation is powerful, but it should be used carefully to keep SLA data consistent and meaningful. A few tips:

• Test before applying widely – run a recalculation on a small project or issue set first to confirm the results.
  
  
• Document policy changes – note when calendars, goals, or conditions were updated so recalculated data has proper context.
  
  
• Focus on real gaps – use recalculation to correct meaningful errors (such as incorrect calendars, priority changes, or misconfigured goals), not as a routine fix.
  
  

Done right, recalculation keeps SLA tracking accurate without adding noise or confusion.

What’s your experience with SLA recalculation? Share them in the comments :)