How to Troubleshoot SLAs in Jira Service Management

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform Notice: Server and Data Center Only - This article only applies to Atlassian products on the server and data center platforms.

Purpose

Understanding how to troubleshoot SLA related issues in Jira Service Management and knowing where to find the information to pin point the cause of the problem. This documentation aims to provide a foundation for SLA troubleshooting (aka First Aid); it will not solve every SLA issues but it will provide a basic troubleshooting guideline for the readers to follow.

Pro Tip

  • Always search for the symptoms in public KB articles or our public bug tracker jira.atlassian.com as there may be known issues / bugs around certain problems.
  • Make sure that you enable DEBUG logging on the com.atlassian.servicedesk.internal.sla package so that you can see the SLA log in Jira log. We describe how to do this in our Logging and profiling documentation.

Things to Remember

  • The creation of a new SLA will result in the creation of a new custom field. For example, if you create an SLA named Time For First Response in a Service Management project; a new custom field will be created with the exact same name.
  • Only Service Management Agents are able to view the SLA metrics on a particular issue. So if a customer complains of missing SLA, you can check to see if they are an Agent before you look into other potential causes. This is covered further in Setting up service project users.

Solution

Prerequisites

At least have a basic understanding on how to use SLA in Jira Service Management. Please refer to Setting up SLAs for further information about this.

Common SLA Issues

Inconsistent SLA

Scenario

Users complain of SLA inconsistency. SLA is not showing the expected value or in some cases, it is even missing.

Have You Tried The Following?
  • Do an SLA recalculation. This can be done by editing an existing SLA and then saving the changes. Do note that this will only affect open issues and resolved issues will not be recalculated.
  • Check for Slow JQL in the SLA goal.  Especially if you are using something like "was in" or "Entered Status". In a very large instance of Jira Service Management, this can cause delays. 
  • Check if the goals of the SLA have been changed? If issue data changes in such a way that the goals for the issue changes (for example, the priority changes from Critical to Blocker), the time against the previous goal will be tracked against the new goal. In other words, if the support team spent an hour on a Critical issue when the issue is escalated to Blocker, the hour still counts against the new goal, even if it causes the SLA to be breached.
  • Check how the users are assigned to the ticket? This is especially true when SLA conditions are based on the assignee. There is an SLA Service Management bug that prevents the SLA condition from being triggered when the ticket is assigned to a user on creation. See JSD-811 - Getting issue details... STATUS for more info.
  • Cross-check with database information. Does the SLA information on the issue detail screen match the information from the database?

    To Query The SLA List
    SELECT * FROM "AO_54307E_TIMEMETRIC";

    The above query will return the list of SLA on the instance. It will also return the SLA ID which you can use for the REST API call method later.

    SELECT ( p.pkey 
             || '-' 
             || i.issuenum ) AS issuekey, 
           cf.cfname, 
           cv.textvalue 
    FROM   customfield cf, 
           customfieldvalue cv, 
           jiraissue i, 
           project p 
    WHERE  i.project = p.id 
           AND cv.issue = i.id 
           AND cv.customfield = cf.id 
           AND cf.customfieldtypekey = 'com.atlassian.servicedesk:sd-sla-field' 
           AND p.pkey = 'TEST' 
           AND i.issuenum IN ( 1, 2 );

    The query above will return the SLA information (for all SLA fields types) for ticket TEST-1 and TEST-2. If you remove the p.pkey = 'TEST' and i.issuenum in (1,2) ; it will return all issues from all projects.

  • Alternatively, you can also cross-check it directly via REST API call. This will return SLA information from the database.

    To Query For A Specific SLA
    https://<ATLASSIAN_DOMAIN>/rest/servicedesk/1/servicedesk/<PROJECT_KEY>/sla/debug/issue/<TICKET_ID>/metric/<SLA_ID>/data

SLA Rule Overload

Scenario

The Service Management SLA configuration page is taking a long time to load and it eventually crashes with an error.

Have You Tried The Following?

  • Did you check the number of rules/conditions for each SLA in the project? The application's unresponsiveness/time may be due to the large number of rules under an SLA. At times, it also could be caused by the complex JQL query, requiring huge amount of time to run it. (Our proxy have a default 60 seconds timeout, any request that hit one minute to return will be terminated by proxy first)

    select g."JQL_QUERY", vp."NAME"
    from "AO_54307E_GOAL" g, "AO_54307E_TIMEMETRIC" tm, "AO_54307E_VIEWPORT" vp
    where g."TIME_METRIC_ID" = tm."ID"
    and tm."SERVICE_DESK_ID" = vp."ID"
    and vp."KEY" = 'test';

    The query above will return all the rules under the test project. The more rules the SLA has the more rules it has to process. In some cases, the user has like 100+ rules causing a time out on the SLA configuration page.

  • Known bugs: There is also a known bug with SLA page loading as detailed in  JSD-2932 - Getting issue details... STATUS , which can cause this behaviour.

Deciphering SLA Data

This section is dedicated to understanding the information you've collected from the troubleshooting steps above. SLA data is stored in the database in JSON, as per the example below.

{
    "timeline":{
        "events":[
            {
                "date":1440587743167,
                "types":[
                    "START"
                ]
            }
        ]
    },
    "ongoingSLAData":{
        "goalId":8,
        "startTime":1440587743167,
        "paused":false,
        "thresholdData":{
            "calculatedAt":1441192543192,
            "remainingTime":-115200025,
            "thresholdsConfigChangeDate":1440585575158
        }
    },
    "completeSLAData":[
    ],
    "metricId":4,
    "definitionChangeDate":0,
    "goalsChangeDate":1440585575204,
    "goalTimeUpdatedDate":1440585575193
}

So how do you know what is the startTime field? You can go to http://www.epochconverter.com/ to convert the value to a more readable human format. Once converted, you will know that the startTime for the SLA is Wed, 26 Aug 2015 11:15:43 GMT.

More on Database

In general, the SLA's are stored in the database and the relationship is as below:

Service Management reference to the project can be attained from "AO_54307E_VIEWPORT" table.

Click for definition

jira=# \d "AO_54307E_VIEWPORT"

                                           Table "public.AO_54307E_VIEWPORT"
          Column          |          Type          |                             Modifiers
--------------------------+------------------------+-------------------------------------------------------------------
 DESCRIPTION              | text                   |
 ID                       | integer                | not null default nextval('"AO_54307E_VIEWPORT_ID_seq"'::regclass)
 KEY                      | character varying(255) | not null
 LOGO_ID                  | integer                |
 NAME                     | character varying(255) | not null
 PROJECT_ID               | bigint                 | not null
 SEND_EMAIL_NOTIFICATIONS | boolean                |
 THEME_ID                 | integer                |

Then, the table "AO_54307E_TIMEMETRIC" associate Service Management to the SLA created, and to the custom field. In simple:

"AO_54307E_TIMEMETRIC" ."SERVICE_DESK_ID" = "AO_54307E_VIEWPORT" ."ID"

"AO_54307E_TIMEMETRIC" ."CUSTOM_FIELD_ID" = customfield.id = customfieldvalue.customfield

Click for definition

jira=# \d "AO_54307E_TIMEMETRIC"

                                                Table "public.AO_54307E_TIMEMETRIC"
            Column             |            Type             |                              Modifiers
-------------------------------+-----------------------------+---------------------------------------------------------------------
 CUSTOM_FIELD_ID               | bigint                      |
 DEFINITION_CHANGE_DATE        | timestamp without time zone |
 GOALS_CHANGE_DATE             | timestamp without time zone |
 ID                            | integer                     | not null default nextval('"AO_54307E_TIMEMETRIC_ID_seq"'::regclass)
 NAME                          | character varying(255)      | not null
 SERVICE_DESK_ID               | integer                     | not null
 THRESHOLDS_CONFIG_CHANGE_DATE | timestamp without time zone |

Lastly, the SLA is tied to the JQL query for the list of the issues at the "AO_54307E_GOAL" table.

"AO_54307E_GOAL"."TIME_METRIC_ID""AO_54307E_TIMEMETRIC"."ID"

Click for definition

jira=# \d "AO_54307E_GOAL"

                                          Table "public.AO_54307E_GOAL"
      Column       |            Type             |                           Modifiers
-------------------+-----------------------------+---------------------------------------------------------------
 DEFAULT_GOAL      | boolean                     |
 ID                | integer                     | not null default nextval('"AO_54307E_GOAL_ID_seq"'::regclass)
 JQL_QUERY         | text                        |
 POS               | integer                     | not null default 0
 TARGET_DURATION   | bigint                      |
 TIME_METRIC_ID    | integer                     | not null
 TIME_UPDATED_DATE | timestamp without time zone |
 CALENDAR_ID       | integer                     |

Then, the table "AO_54307E_TIMEMETRIC" associate Service Management to the SLA created, and to the custom field. In simple:

"AO_54307E_TIMEMETRIC" ."SERVICE_DESK_ID" = "AO_54307E_VIEWPORT" ."ID"

"AO_54307E_TIMEMETRIC" ."CUSTOM_FIELD_ID" = customfield.id = customfieldvalue.customfield

Click for definition
jira=# \d "AO_54307E_TIMEMETRIC"
                                                Table "public.AO_54307E_TIMEMETRIC"
            Column             |            Type             |                              Modifiers
-------------------------------+-----------------------------+---------------------------------------------------------------------
 CUSTOM_FIELD_ID               | bigint                      |
 DEFINITION_CHANGE_DATE        | timestamp without time zone |
 GOALS_CHANGE_DATE             | timestamp without time zone |
 ID                            | integer                     | not null default nextval('"AO_54307E_TIMEMETRIC_ID_seq"'::regclass)
 NAME                          | character varying(255)      | not null
 SERVICE_DESK_ID               | integer                     | not null
 THRESHOLDS_CONFIG_CHANGE_DATE | timestamp without time zone |
DescriptionUnderstanding how to troubleshoot SLA related issues in Jira Service Management and knowing where to find the information to pinpoint the cause of the problem. This documentation aims to provide a foundation for SLA troubleshooting (aka First Aid); it will not solve every SLA issues but it will provide a basic troubleshooting guideline
ProductJira
PlatformServer
Last modified on Sep 28, 2021

Was this helpful?

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