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 Agreements (SLA) by using the SLA Reconstruction Resource to recalculate open and ongoing SLAs.
Solution
Before any destructive action
SLA values often self-correct as missed events catch up. If a single issue is wrong, a Jira Admin can use the Update SLAs refresh button in the issue's SLA panel — no API calls, no automation, and it is non-destructive. Only use the REST reconstruction below if the button does not resolve it.
Occasionally, events that should trigger a change to an SLA value are missed or interpreted incorrectly, resulting in an incorrect SLA value being displayed 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 is incorrect, or SLA was 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 occur when SLAs are changed after their cycles have completed 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 the 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
Resetting SLA for a single issue
Jira Admins can use a "Recalculate SLAs" button in the SLA panel to re-run the SLA calculation for that issue based on the current SLA configuration — no API calls or automation rules needed.
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 unlike graceful recalculation, it won’t perform any checks or attempt to repair the timeline. Instead, it would simply replace the old SLA value with the newly calculated one.
Pick the right recalculation type
Type | How it's triggered | Destructive? | When to use |
|---|---|---|---|
Non-destructive | Automatic on SLA config change; "Recalculate SLAs" button for one issue | No | First choice |
Graceful destructive (force=false) | Debug REST endpoint | Yes — repairs timeline | Running SLAs with the wrong order of events |
Forceful destructive (force=true) | Debug REST endpoint | Yes — no checks | Last resort only |
Steps to recalculate SLA
May result in data loss — not reversible
The destructive reconstruction deletes all existing SLA data for the specified tickets and recalculates against current SLA goals. A target met under an old goal can become breached under a new one. Don't run it unless you are certain.
You must have Jira Administrator permissions and be an Agent in the target projects. Use force=false in step 2.b for running SLAs.
Optional: Install Postman. It's free and provides a nice User Interface to help you send 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.
In 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.
In Postman, click Authorization, then select 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.
Verification steps
Confirm the request returned status 200 (Postman shows it in the bottom-right).
Expect the SLA to temporarily disappear from the queue/issue view while it re-indexes — the message "Could not load SLA. SLA may be indexing due to configuration updates" is normal during this window.
For large batches (e.g. 1,000+ issues) allow time for the value to repopulate before concluding it failed.
Recalculate SLA with the cURL command
If you prefer, use cURL commands on a terminal to recalculate your SLAs. Here's how the command should look 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, temporarily removing the SLA value from the queue view (for example) for 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?