nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

Fabio Racobaldo _Catworkx_

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

All comments

Fabio Racobaldo _Catworkx_

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

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.

Using Time Metrics Tracker you can closely monitor how long it takes to resolve tasks, identify bottlenecks, and optimize your team’s resolution process.

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-service-management-cloud

jira-service-management

jsm