Recalculate inconsistent SLAs with Automation in Jira Service Management

Summary

Quickly resolve inconsistent SLAs in Jira Service Management with an automated workaround to recalculate SLAs.

Solution

Why do SLAs become inconsistent?

SLA inconsistency typically occurs after an SLA configuration change, a workflow/status change, or a goal/calendar edit applied to work items that already exist — because existing SLAs are not retroactively recomputed.

When won't this help?

• If the SLA is still wrong after recalculation, the SLA definition itself (goals, calendar, start/stop/pause conditions) is likely misconfigured — recalculation replays the current config, it does not fix the config.

• This is a Cloud-only workaround; the Actions-menu manual trigger and automation triggers referenced here are Cloud features.

Use a manual trigger to recalculate the SLA for a single work item

Manual triggers can be accessed from the Actions menu, right next to the Status on the work item view. Configure an automation rule as follows:

1. Trigger: Manual trigger - You can further specify which users run this rule by selecting a group in the manual trigger.

2. Action: Send web request.

   • Web request URL :

     https://<instance_name>.atlassian.net/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct?force=true
     The destructive recalculation is used as a last resort when the customers have the wrong SLA state or value for specific Jira issues. (force = false/true)

     Graceful destructive recalculation would calculate a new SLA value and compare the timeline with the previous SLA value to see if the event order is wrong. If it is, it will sort the timeline events by their timestamp and update the SLA value with the new timeline and new state and value. It is destructive, as it would re-create the ongoing data from a new timeline. Internally it uses the same algorithm as the normal, non-destructive recalculation, to calculate the new timeline.

     The forceful destructive recalculation would, again, calculate a new SLA value. But in contrast with graceful recalculation, it won’t perform any checks or try to repair the timeline. Instead, it would simply replace the old SLA value with the newly calculated one.

   • Use the headers below:

     • Content-Type set as application/json.

     • Authorization set as Basic "email:API Token".

       You can construct and send basic auth headers. To do this, perform the following steps:

       1. Generate an API token for Jira using your Atlassian Account.

       2. Build a string of the form useremail:api_token.

       3. BASE64 encode the string:

          • Linux/Unix/MacOS:

            echo -n user@example.com:api_token_string | base64

          • Windows 7 and later, using Microsoft PowerShell:

            $Text = ‘user@example.com:api_token_string’ $Bytes = [System.Text.Encoding]::UTF8.GetBytes($Text) $EncodedText = [Convert]::ToBase64String($Bytes) $EncodedText

     • HTTP Method: POST.

     • Web Request Body: Custom data.

     • Custom Data:

       ["{{issue.key}}"]

3. Whenever the SLA for a work item needs to be recalculated, go to the Actions Menu and trigger this automation rule.

Perform the SLA recalculation on multiple work items at the same time

1. Trigger: Schedule/Manual Trigger.

2. Advanced condition: JQL. Use a JQL to filter the work items on which the endpoint will be forced.

3. Inside the JQL condition branch, add the Action: Send web request. Use the same configuration from step 2 in the previous rule.

   Important points to remember when using the JQL or any advanced branching

   • Ensure that this is a project-level rule and not a global/multiple project rule so that it doesn't exhaust your global execution limits.

   • Be sure to use an efficient query that would list the affected issues. You can consider using labels for ease.

   • Be sure that the query isn't returning more than 1000 issues at a time by validating it. You can consider refining your query if you get more results or use labels to break down the result set.

   • Ensure that you are running this in batches on a smaller subset of issues to avoid performance impact(preferably less than 200 issues).

   • Be aware of the Automation service limits.

How to confirm whether the recalculation worked?

After recalculation, open an affected work item and confirm the SLA panel shows the expected elapsed/remaining time.

For bulk updates, also check the automation audit log for successful executions.

We are tracking an open feature request for the option to reset SLA from the work item view:

• JSDCLOUD-194 - Ability to reset the SLA

Related article:

• SLAs in Jira Service Management are missing or disappear