Understanding my SLAs Part I — Scheduled jobs and the TASK SLA

[iris_geist]

Quite often I hear "I don't understand my SLA results" or "I got a call from my customer who is really mad that his SLA expired, but I don't think it did, did it?" We go through a process of considering, preparing, planning and reviewing how we want our SLA agreements with the end users in mind, and once set up, they still manage to surprise us occasionally. Understanding your SLAs and the "quirks" that come with Scheduled Jobs and the TASK SLA is the first step in helping to clear the haze around using SLAs.

First things first, is knowing how the numbers in the Task SLAs related list of your incident have come to be.

When you look at your SLAs from an incident, you will see something like this:

The state of your SLA is "in progress," it started on 12-12 at 20:49:39 (by the way, that was a Friday), and it shows the actual elapsed time of 2 days, 7 hours 13 minutes, and the actual elapsed percentage of 690.38. Looking at the time, I can see that right now is 12-15 at 9:44 am. If the task does not reach the stop condition by a set amount of time, it is marked Breached.

Finding the missing time in your SLA workflow

If I add 2 days and 7 hours and 13 Minutes to 12-12 20:49, I end up at 12-15 at   4:02 in the morning. Where did the missing 5 hours and 42 minutes go?

You can find where those missing minutes went by digging into your SLAs under System Scheduler > Scheduled Jobs.

When searching for scheduled jobs with a name that contains SLA, we can find the SLA breach calculation jobs. Our SLA has an elapsed percentage of >100%, meaning, it has already breached. The scheduled job for already breached jobs runs at around 4 AM (sound familiar?) and runs only once a day.

As you can now see, the information in the Task SLA, unless the system property named "glide.sla.calculate_on_display" is set to true, will show the times and percentages of when the matching scheduled job was last run. It will not the times and percentages as of "right now." With the property set to true, the Task SLA will be recalculated every time someone opens the incident up to view its details.

The Task SLA is calculated independently (through scheduled jobs) from the SLA breach percentage notifications (in the SLA workflow). This independent calculation works well, unless more work is added into the SLA workflows. If additional activities are added to that workflow, this will slow down the flow through the workflow, adding un-accounted-for seconds to the notification workflow and causing the two independent calculations to grow apart.

This still leaves us with the possibility of a customer who calls in saying that the SLA has breached, but it does not show as breached in your report you just sent to him — how did that happen? I will walk you through some of the differences between actual and business times and percentages in Understanding my SLAs part II.

For part 2, check out Understanding my SLAs Part II - The Difference between Actual and Business elapsed times