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; } } }

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 ?

Accepted answers

All comments

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

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

TIS - Cycle Time report.PNG

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.

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)

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🤠

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.

1773829961812 (1).png

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.
Frame 6273258.png

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

Regards!

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

Martin Sturm - JXL

Hello @Debbie Crum,

This is a common pain point. By default Jira measures resolution as the total calendar time from creation to closed, so it includes every day the ticket sat waiting on the requestor, and Jira won't pause that clock for specific statuses on its own. A few native options depending on your product:

- Jira Service Management: model this with an SLA. Create a custom SLA metric (Project settings > SLAs) and set the start/stop/pause conditions so the timer pauses while the issue is in Pending Testing, Pending Response, or Hold. The SLA then reflects only the time your team was actively working.
- Jira Software: the Control Chart (in your board's reports) lets you choose which statuses to include in the cycle time calculation, so you can leave out the waiting statuses and measure active work only.
- Lighter option: use automation to stamp a date/time field each time the issue enters and leaves a working status, then report on the difference.

The SLA route is usually the cleanest if you have JSM, since the pause conditions map exactly to your "waiting on requestor" scenario.

Best,

Martin

Martin Sturm - JXL

Following up on the cycle-time and SLA ideas, here's another angle if you'd rather see the per-status breakdown directly in a list.

If you're open to an app from the Atlassian Marketplace, JXL for Jira (the app my team and I work on) adds history-based smart columns to a spreadsheet-style view of your issues. A Time between statuses column lets you measure only the span between, say, Open and Pending Testing, so the 10 days spent waiting on the requestor never lands in your team's number. You can also add a per-status Time in status column, and apply a work calendar so it counts business hours only.

Hope this gives you another option,

Martin

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-cloud