Time to resolve (avg) & Elapsed Time

[Raheem Pillay]

Hello,

I was messing around with the custom reports in JSM and exploring the pre defined metrics JSM provides, more specifically the time to resolve (avg).

I wanted to know how its being calculated and what JSM is looking at to work out the avg. When I go look at a data point, it is giving me the elapsed time of a ticket. At fist I thought it was just how long it took to resolve a ticket using created & resolved date/time. But it seems to look at your SLAs although am not sure what specifically its looking at

You can see in the screen shots its identified some with low elapsed time such as 0:01 and then there are others which are not like that.

So am just trying to understand how the JSM calculates the time to resolve (avg) and what potentially is the reasons around the low elapsed times.

[Fabio Racobaldo _Catworkx_ · Accepted solution]

Hello @Raheem Pillay ,

this shloud be the average time between start and stop condition related to Time to resolve SLA configuration.

If you have some paused conditions, for example, time spent on that conditions will be decreased from the elapsed time.

Hope this helps,

Fabio

[Raheem Pillay]

Hi @Fabio Racobaldo _Catworkx_ ,

Thanks for the explanation, we do have a paused condition when a ticket gets resolved as a customer might reopen it. It only fully tops when it closes. 

Going by your explanation that will be playing apart into the elapsed time? 

[Fabio Racobaldo _Catworkx_]

Hey @Raheem Pillay ,

please share your SLA configuration in order to better understand your scenario.

BTW, based on that time to resolve avg is based on creation date and resolved date. Please take a look also to your calendar/s in order to fully inderstand when SLA is in progress or stopped.

Fabio

[Raheem Pillay]

Hi @Fabio Racobaldo _Catworkx_ ,

Looking at the configuration it pauses when it enters the resolve status. 

[Fabio Racobaldo _Catworkx_]

Hey @Raheem Pillay ,

it means that Time to resolve is Resolution Date - Creation Date - (time in status Pending). Moreover you need to check the calendar. When a ticket is out of working hours it is automatically stopped.

Hope this clarifies,

Fabio

[Anastasiia Maliei SaaSJet]

Hi, @Raheem Pillay 

What JSM shows there is usually SLA time, not just the full time from Created → Resolved.

So if you’re seeing very low values like 0:01, that’s often because of things like:

• the SLA starting later than ticket creation
• pause conditions
• business hours/calendar rules
• or just the way the value is rounded in the report

So yes, the ticket may have existed much longer, but the SLA clock may have counted only a small part of that time.

If your goal is to understand why the numbers differ, it can also help to compare the SLA metric with a separate workflow-based metric. For example, with Time Metrics Tracker | Time Between Statuses, you can measure raw Created → Resolved time, time in specific statuses, waiting time, or time between workflow stages. That makes it much easier to see whether the low value comes from SLA logic, pauses, or the actual workflow being very short.