Resolve Wrong or Missing SLAs in Jira Service Management Cloud

Platform Notice: Cloud - This article applies to Atlassian products on the cloud platform.

This KB article is for Jira Service Management Cloud. For the Server equivalent, see Missing SLA data in Jira Service Management.

Problem

Incorrect SLA values or SLA values are not updating after issue events

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, you can use the SLA Reconstruction Resource to trigger a recalculation of all open or ongoing SLAs for a list of issues. 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

If an SLA has been incorrectly stopped or closed SLA cycles are wrong, it is possible to use the SLA Reconstruction Resource to forcibly recreate the entire SLA value, including completed cycles, from the recorded issue history. In the workaround described below, use force=true as the URL parameter in step 2.b.


This operation destroys all existing SLA data for the specified tickets, and therefore should not be performed unless you are really sure that you want to reconstruct the SLAs. This operation is not reversible and may result in data loss.

What do we mean by data loss?

We meant old SLA data loss. This can happen in cases where the SLAs changed after their cycles were complete on a ticket.

For instance, let's say 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 that 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 and all of its data, just the SLA data specifically (and other JSM features that may use it ie: reports).

Solution

There are three kinds of full SLA recalculation:

  1. Non-destructive recalculation, triggered automatically whenever SLA configuration is changed, applied to all open issues

  2. Graceful destructive recalculation, triggered from a debug REST endpoint (force=false)

  3. Forceful destructive recalculation, triggered from a debug REST endpoint (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.

The 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.

Workaround

  1. 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.

  2. Create a new request with Postman

    1. Choose the type POST.

    2. 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=false
    3. In the Body tab right below the URL, select raw and JSON.

    4. On the text box, add the affected tickets using the format ["TICKET-001", "TICKET-002", ... , "TICKET-1234"].
  3. Authenticate with your Atlassian account. To do this, create an API token.

    1. Go to https://id.atlassian.com/manage/api-tokens > API Tokens > Create API Token

    2. Add a label and click Create and your token is ready to go.

  4. On Postman again, click on Authorization, and select the type Basic Auth.

    1. Type the email you use to log in to your Service Management site.

    2. On Password, paste the token you generated in the previous step.

  5. With everything configured, it's time to correct the SLAs. To do this, just click SEND.

  6. Once you click SEND, if everything goes well, it will show the status 200 in the bottom right corner.

cURL Command

If you prefer, you can 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"]'

What does the SLA look like in the UI during a recalculation?

When an SLA is updated for a Jira Issue it will show the following:

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.

Requirements

  • The user must have Jira Administrator permissions and must be an Agent in the target projects.
Last modified on Nov 8, 2024

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.