Tracking Question

[Debbie Crum]

In jira, we have different status of Tickets, Open, Hold, Pending Response, Pending Testing etc.   I am having trouble finding a way to accurately tracking how long my team is taking actually resolving the tickets.   For Example to be simple.. The Ticket is opened on 1/1/2026 and moved to the Pending Testing Status on 1/5/2026.    The requestor does not test until 1/15/2026 and approved.  The ticket is closed out as resolved on 1/15/2026.  Once the ticket is moved to closed it shows it took my time 15 days to resolve, when in actuality it only took them 5 days.. The other 10 were waiting on the requestor. 

Any thoughts or suggestions on how anyone has delt with this issue ?

[Rahul_RVS]

Hi @Debbie Crum 

As John suggested, a mktplace app can help here. For detailed reporting for cycle times / time in status for your issues, if you would like to try out one, pls explore

Time in Status Reports 

With this app you generate time in each workflow status for multiple issues with multiple filter and grouping options. It works for current issues and closed ones as well.

The report below shows the cycle time of the issues. This can be achieved by the status grouping feature of the app, wherein you can define your own cycle/resolution times by grouping up specific statuses.

The calendar setting feature allows to define your working days and times. The app will calculate time in status based on this calendar only.

The app can be easily added as a dashboard gadget and can be shared with colleagues.

More details here.

Disclaimer : I am part of the app team for this add-on 

[John Funk]

Hi Debbie,

I would suggest using one of the vey good Time in Status Marketplace apps. Most are inexpensive or even free. 

https://marketplace.atlassian.com/search?query=Time+in+Status&hosting=cloud

[Birkan Yildiz _OBSS_]

Hey @Debbie Crum 
First, welcome to the Community!

Yes, native Jira calculates the total resolution time continuously from creation to closure, including all the time a ticket spends waiting on requestors or third parties. It doesn't natively allow you to "pause" the timer for specific waiting statuses.

If you are open to using a Marketplace app, you can easily track the actual active resolution time using Timepiece - Time in Status for Jira.

Here is how you can set it up to get the exact 5-day duration you need:

Select the Duration Between Statuses report and click the Metrics button to define a custom metric. Set Start At to "Open" and Stop At to "Closed". Then, select your waiting statuses (like "Hold", "Pending Response", and "Pending Testing") in the Paused On option.  

The metric will automatically pause counting whenever the ticket enters these statuses and resume when it moves back to an active status.

Pro tip: You can also apply Timepiece's Custom Calendars to automatically exclude weekends, nights, and public holidays from this calculation, giving you the true business time spent resolving the ticket.

And with the AI-powered Timepiece Assistant, you can type a prompt like "Show me the duration from creation to closed, but skip the time tickets spent in Pending Testing or Hold," and it will instantly generate a ready-to-use report for you.

You can find Timepiece - Time in Status for Jira on the Atlassian Marketplace.

Full disclosure: I'm on the team that makes Timepiece. Hope this helps.

Best,
Birkan

[Alina Kurinna _SaaSJet_]

Hi @Debbie Crum 

As mentioned in the previous comments, a Time In Status solution could be a good fit for this case.

My team, SaaSJet, developed Time in Status for Jira, which helps you see exactly how long an issue spends in each workflow status.

For example, you could separate working time statuses, such as In Progress, Testing from waiting time statuses, such as Waiting for Requester or Pending Testing. Even without grouping, the per-status breakdown already shows Pending Testing as its own 10-day column, so the waiting time stops hiding inside your resolution metric. There's also a work-schedule setting if you want the numbers based on business hours only.

This makes it easier to understand the actual time your team was working on an issue, instead of only looking at the full period between Open and Closed.

Additionally, if you need to define a target and manage the process proactively, you could also consider SLA Time and Report for Jira, another app developed by my team.
With this app, you can configure an SLA to start when work begins, pause when the issue moves to a status such as Waiting for Requester, and stop when it is resolved. This gives you a clearer view of active resolution time.
You can also set goals and automate actions when an issue is approaching or exceeding its target. For example, the app can send a notification, change the assignee or priority, move the issue to another status, or escalate it to a manager.

I hope this helps. Please feel free to reach out if you have any questions.

Regards!

[Arkadiusz Wroblewski]

Hello @Debbie Crum 

The built-in Control Chart can calculate cycle time based only on the statuses you select. For example, you could include only the statuses where your team is actively working and exclude statuses such as Pending Testing, Pending Response, or Hold.

View and understand the control chart | Jira Cloud | Atlassian Support

Best,

Arkadiusz🤠

[Bartek Szajkowski _ Orbiscend OU]

Hello @Debbie Crum 

Thanks for your question.

If you are open for third-party app, from Marketplace, I would like to recommend to check our JQL Argon app JQL Argon Powerful Search 

 

JQL Argon's with function: timeInStatus solves this directly. Instead of measuring total calendar time (open → closed), you measure time only in active work statuses, excluding waiting ones.

---

The approach: Query time spent in statuses where your team is actually working — not the statuses where the ball is in the requestor's court.

Example  — Find issues where active work time exceeded 5 days:

issue > timeInStatus("project = SUPPORT", "In Progress", "5d")

JQL Argon doesn't yet support summing multiple statuses in one call, but you can layer queries or use the Time in Status custom field to track each status separately.

I hope my answer will be helpful for you.

Greetings
Bartek from Orbiscend (JQL Argon app provider)

[VENKATESWARLU KURUVA]

Hi @Debbie Crum ,

Tracking Actual Resolution Time
There are three approaches, from built-in to advanced:

1. Use JSM SLAs with Time Metrics (Built-in — Best Option)
If you're on Jira Service Management, this is solved natively:

Go to Project Settings → SLAs and create a custom SLA metric (e.g., "Actual Resolution Time").

Under Start/Stop conditions, configure it to pause the clock on statuses like Pending Testing, Pending Response, Hold — any status where your team is waiting on the customer.

The SLA timer only counts time in statuses where your team is actively working.

2. Use Status Categories Strategically (Jira Software — No Apps)
If you're not on JSM, you can get partial tracking:

Map your statuses into status categories intentionally:

In Progress category → statuses where your team works (Open, In Progress)

Waiting → use a custom category or track separately

Then use Jira dashboards with the "Average Time in Status" or Control Chart to filter by specific statuses.

This won't auto-exclude wait time, but you can manually calculate: Total time − Time in "Pending" statuses = Actual resolution time.

3. Use a Marketplace App (Most Flexible)
For detailed, automated reporting across many tickets:

Time in Status Reports for Jira | Atlassian Marketplace — lets you group statuses into "active work" vs. "waiting" and calculates cycle time accordingly. Supports calendar/working-hours settings.

Search Results | Atlassian Marketplace — several options available, most with free tiers.

These apps give you dashboard gadgets showing per-ticket and aggregate cycle times with wait-time exclusions.