Incorrect SLA Measurement

[Nor Liana (AKATI Sekurity)]

Hello everyone,

I'm checking my tickets SLA, and it seems...a bit absurd. So I compared with manual calculation, and it is very, very,very different.

For example, a ticket that is resolved in less than 1 day (less than 24 hours) in Jira it shown as taking hundreds of hours:

I've checked the SLA configuration for my project, and nothing seems to be out of place:

So I'm a bit stumped. This will affect greatly in our upcoming monthly SLA report.

What should I troubleshoot?

[Mariana_Pryshliak_Saasjet · Accepted solution]

Hello @Nor Liana (AKATI Sekurity) 

It seems JD has some defects.
Another thing is your start condition: Issue created & Resolution - Cleared.
Please check what the resolution Jira posts automatically when an issue created.
If it set Cleared by default, then it seems some defect here.
If you set it manually, then check the history of when the Start event happened (Created + Cleared) and what's the conditions for Stop and Pause.

I hope it helps

[Nor Liana (AKATI Sekurity)]

This was it! 

I didn't notice the Resolution: Cleared part. Once I removed it, the SLA works fine. Thanks Mariana!

[Tuncay Senturk]

Hi @Nor Liana (AKATI Sekurity) 

As @Gökçe Gürsel {Appfire} mentioned, issue history would definitely help. 

Bear in mind that the resolution field and the Resolution status are generally confusing in Jira regarding Time to Resolution SLA. It ends whenever the resolution field of the issue is set, not when the status reaches to Resolved status.

Sometimes, workflow transition to Resolved status might have a lacking post function (set resolution field) and it can be set when the issue is Closed. So the SLA ends in Closed transition rather than Resolved status.

Could it be similar to your problem?

Tuncay

[Nor Liana (AKATI Sekurity)]

Most of our tickets were Resolved manually through the Resolution field.

But the thing is, it shown as overdue even before Resolution status is changed. For example, I resolved a ticket 3 hours after creation, within the SLA of 16 hours, yet it had already shown as overdue of -40h. 

To be honest, the configuration and its end results in Jira is a bit confusing to me...

[Gökçe Gürsel {Appfire}]

hi @Nor Liana (AKATI Sekurity) ,

My first action would be checking the SLA configuration and the issue history in this case. If you could share the history of one of the problematic issue and the SLa configuration, I'd be more than happy to help you.

Cheers,

Gökçe

[Nor Liana (AKATI Sekurity)]

Morning Gökçe,

Below is a sample of issue history (with confidential information redacted). The SLA configuration is the same as the one shown in the main post (or is there somewhere else I need to check? To be honest, it is a bit confusing going around the project settings in Jira, so I might be missing something).



As we can see, it is created and resolved within the same day, yet the SLA shown it to be overdue at -40h 20m. A significant difference. It shouldn't be overdue, as the Time Goal for this one is 16h. 

To note, the overdue SLA had shown to be in the rest even before I resolve the ticket, which is...absurd, considering I resolved it 3 hours after creation.

[Gökçe Gürsel {Appfire}]

Hi @Nor Liana (AKATI Sekurity) ,

Can you send a screenshot of your SLA definition? 

Thanks,

Gökçe