Missing or corrupted SLA data in Jira Service Management

Still need help?

The Atlassian Community is here for you.

Ask the community

This article is about Jira Service Management Server. For the Cloud equivalent, see SLAs in Jira Service Management are missing or disappear.


Problem

In Jira Service Management, there can be an occurrence where the SLA data for the issue is missing or doesn't stop when they should be. This Knowledge Base does not provide information on how to solve the issue once and for all, as the root cause can varies from add-ons/database corruption/other unknown cause, but to provide a viable workaround for the missing SLA.

Diagnosis

Environment

  • Jira Service Management Server version 3.0.3 or above

Symptoms

  • Example case is the missing 'Initial Reaction Time' SLA in the issue
  • SLA is not showing on both ticket and issue navigator searches
  • There are SLA data in the database for the affected issues but the SLA is either missing or incorrectly displayed on the UI e.g. still running when they should already be stopped.
    • Refer to this documentation to verify from the database the SLA data is indeed missing

Cause

Multiple cause at the moment:

Workaround

Below are ways to temporally circumvent a problem, although it still exists in the application.

REST call SLA reconstruction only available on JSD v3.0.3 and above
  • If you are running JSD 4.3.0 and above, you will need to first enable the dark feature sd.sla.fix.timeline.enabled per the instructions in Enable Dark Feature in Jira:

    • Navigate to the following page to access the Dark Features page:

      <baseUrl>/secure/admin/SiteDarkFeatures!Default.jspa
    • Enter sd.sla.fix.timeline.enabled in the field “Enable dark feature” and clicking on the “Add” button, and verify that the dark feature sd.sla.fix.timeline.enabled is showing:
  • Perform a POST- REST call to the Jira instance through the following URL:

    <baseUrl>/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct
  • In the Authorization tab, select 'Basic Auth' type and supply your Jira credentials accordingly
  • Along with header: "Content-Type: application/json" and raw JSON data below within the Body section.

    ["ISSUEKEY-XXX", "ISSUEKEY-XXXX"]
  • Key in the issue key for the issue which has the missing SLA.

    You may install Postman offered by Chrome Web Store to achieve this. Please make sure you're sending a POST request with raw data with JSON application.

    Alternatively, you can use CURL command-line tool to do this:

    $ curl -X POST -u $USERNAME:$PASSWORD -H "Content-Type: application/json" "http://localhost:2990/jira/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct" -d "[\"TEST1-2\", \"TEST1-3\"]"
  • Performing above will trigger a manual reconstruct of the SLA.
  • Navigate to the Service Management Project Administration and click on the "Update" icon under the SLAs section.


Service Management 4.9.1 added a few more REST endpoints to help

  • /rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/jql
    • Similar to "/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct" but it takes a valid JQL expression instead of the list of issues to get the issues to be reconstructed.
    • (warning) Not providing any JQL will cause empty JQL to be executed which will return all issues on the instance, and will run reconstruction on all of them. Use with caution.
$ curl -X POST -u $USERNAME:$PASSWORD -H "Content-Type: application/json" "http://localhost:2990/jira/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/jql" -d "Project=TST"
  • /rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/force
    • Similar to <baseUrl>/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct, but it will not take into account whether any events are missing or out of order. It will recalculate the SLA based on current SLA settings (which might have changed since the time the issue SLAs were calculated) and force overwrite the values in the DB for each issue provided to the API in the request body.
    • (warning) Be EXTREMELY careful when running this one. The changes are irreversible, and the new calculated values will take into account only the current SLA settings that may not be the same as when the SLAs were originally calculated for the ticket.
  • /rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/jql/force
    • Similar to <baseUrl>/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct/jql, but it will not take into account whether any events are missing or out of order. It will recalculate the SLA based on current SLA settings (which might have changed since the time the issue SLAs were calculated) and force overwrite the values in the DB for each issue returned by the provided JQL.
    • (warning) Be EXTREMELY careful when running this one. The changes are irreversible, and the new calculated values will take into account only the current SLA settings that may not be the same as when the SLAs were originally calculated for the ticket.

    • (warning) Not providing any JQL will cause empty JQL to be executed which will return all issues on the instance, and will run reconstruction on all of them. Use with EXTREME caution.


This script was build to help running the "/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct" endpoint using a JQL on versions earlier than 4.9.1.


Resolution

For below root cause:

  • Corrupted database : Above workaround should fix the missing data
  • Plugin Issue : Perform Safe Mode on test instance to see if the SLA is still missing

For other unknown root cause, please consult Atlassian Support for further investigation


Last modified on Jun 21, 2022

Was this helpful?

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