Resolve Wrong or Missing SLAs in Jira Service Management Cloud
Platform Notice: Cloud Only - This article only applies to Atlassian apps on the cloud platform.
Summary
This KB article is for Jira Service Management Cloud. For Data Center, see Missing SLA data in Jira Service Management. Before you proceed:
You must have Jira Administrator permissions and must be an Agent in the target projects.
Learn how to fix incorrect Service Level Agreement (SLA) by using the SLA Reconstruction Resource to recalculate open and ongoing SLAs.
Solution
Occasionally issue events that should trigger a change to an SLA value are missed or interpreted incorrectly, resulting in an incorrect SLA value showing in the queues or issue view. Usually, SLA calculations will catch up to missed events, and SLA values will eventually correct themselves, but if they don’t, use the SLA Reconstruction Resource to trigger a recalculation of all open or ongoing SLAs for a list of issues.
NOTE: This only works for SLAs that are currently running. In the workaround described below, use force=false as the URL parameter in step 2.b.
SLA history incorrect or SLA incorrectly closed
May result in data loss
This operation destroys all existing SLA data for the specified tickets and should not be performed unless you are really sure that you want to reconstruct the SLAs. It is not reversible and may result in data loss.
Data loss can happen when the SLAs are changed after their cycles are complete on a ticket.
For example, there was an SLA target of 4h on a ticket earlier this year, and the agents completed the ticket in 2.5h, well within the target - the SLA cycle would be shown as met. If the SLA was then changed to a 2h target after that ticket was closed, it'd still be shown as met as it'd still be using the old 4h target.
The reconstruction process will delete the old SLA data and recalculate it with current SLA goals so that 2.5h ticket resolution time would mean that now that the ticket's SLA has been breached by half an hour.
It shouldn't affect the ticket itself or its data, just the SLA data.
Recalculate the SLA
There are three kinds of full SLA recalculation:
1. Non-destructive recalculation
Triggered automatically whenever SLA configuration is changed, applied to all open issues.
The non-destructive recalculation is used as a last resort when the customers have the wrong SLA state or value for specific Jira issues.
2. Graceful destructive recalculation
Triggered from a debug REST endpoint (force=false)
The graceful destructive recalculation will 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.
3. Forceful destructive recalculation
Triggered from a debug REST endpoint (force=true)
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.
Steps to recalculate SLA
Optional: Install Postman. It's free and provides a nice User Interface to assist you in sending cURL commands to our API. We'll be using Postman for the next steps, but you can find an example cURL command at the end of the article.
Create a new request with Postman
Choose the type POST.
In the URL box, paste the following URL, replacing mysite.atlassian.net with the link from your site:
https://mysite.atlassian.net/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct?force=falseOn the Body tab, Click raw and JSON.
On the text box, add the affected tickets using the format ["TICKET-001", "TICKET-002", ... , "TICKET-1234"].
Authenticate with your Atlassian account. To do this, create an API token.
Go to Atlassian account > Create API Token.
Add a label and click Create and your token is ready to go.
On Postman again, click on Authorization, and select the type Basic Auth.
Type the email you use to log in to your Service Management site.
On Password, paste the token you generated in the previous step.
With everything configured, it's time to correct the SLAs. To do this, just click SEND.
Once you click SEND, if everything goes well, it will show the "status: 200" in the bottom right corner.
Recalculate SLA with cURL command
If you prefer, use cURL commands on a terminal to recalculate your SLAs. Here's how the command should look like for the same examples used in the steps above:
curl --request POST 'https://mysite.atlassian.net/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct?force=false' \
--header 'Content-Type: application/json' \
--user youremail@company.com:yourapitoken \
--data-raw '["IT-420"]'NOTE: When an SLA is updated for a Jira Work Item, it'll display the message, "Could not load SLA. SLA may be indexing due to configuration updates. If this persists, check the SLA configuration."
The SLA will re-index/re-calculate, which will temporarily remove the SLA value from the queue view (for example) for the open Jira Issues that meet the criteria for having that SLA populated.
Please note that the SLA panel will not show on the Jira Issue(s) view as well, during the recalculation. If the recalculation is to a lot of issues it can take some time for the SLA to populate to the Jira Issue or JSM Queue. For example, if there are 1000 Jira Issues to recalculate an SLA for, using a method mentioned above, this will take some time to re-define the value for the open Jira Issue(s). So, please be patient while this process is completed.
Was this helpful?