What is the correct smart value approach to calculate and format total active time excluding On Hold

[BAL GOVIND YADAV]

Hi Team,

I was working on the use case: Calculate the bug Resolution time,

here it was calculating the time from, issue creation to completion, and it was working fine.

Now I have another use case: for suppose if the issue is kept on HOLD it should stop calculating time when it is ON HOLD and resume when moved to other status and needs to display total time excluding that on hold duration time.

I tried create automation rule and execute but not getting expected result.
Kindly help on it.

Best regards,

Bal Govind Yadav

[Rahul_RVS]

Hi @BAL GOVIND YADAV 

Welcome to the community !!

Automation will not work for historical data. You might have to build a solution using Jira Rest API's or another option could be to try out a mktplace app. If you would be interested in the same, 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.

With Status grouping feature, can help you define your own cycle time / issue age time and view the averages of the same. You can add your specific statuses to the status group to calculate the bug age. Also the app has 20+ reports to meet a variety of use cases.

You can set your own working calendar to exclude weekends and holidays from the time in status calculation.

More details here.

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

[Birkan Yildiz _OBSS_]

Hey @BAL GOVIND YADAV 

First, welcome to the Community!

Trying to calculate durations while pausing the timer for specific statuses using native Jira automation and smart values can quickly become overly complicated and unreliable.
If you are open to using a Marketplace app, you can easily achieve this exact use case without any complex automation rules by using the Duration Between Statuses report in Timepiece - Time in Status for Jira.

Here is exactly how to set it up:

Select the Duration Between Statuses report type and click the Metrics button to define a custom metric.

Set Start At to "Issue Creation" and Stop At to your completion status.

Set the Paused On option to your "On Hold" status.

With this setup, the metric will automatically pause counting whenever the bug enters the "On Hold" status and resume when it moves to another status, giving you the precise total active resolution time excluding the hold duration.

 

Pro tip: You can also apply Timepiece's Custom Calendars to this report to automatically exclude weekends, nights, and public holidays from your total resolution time. And with Timepiece Assistant, you can ask AI to configure any report for you.

You can find Timepiece - Time in Status for Jira on the Atlassian Marketplace. Hope this helps!
Full disclosure, I'm on the team that develops Timepiece.

[Anastasiia Maliei SaaSJet]

Hi, @BAL GOVIND YADAV 

For this use case, the best approach would be to use Time Metric Tracker instead of trying to calculate it manually with smart values in Jira Automation.

You can create the required metric, for your example - Bug Resolution Time, and configure it to calculate the time from issue creation until completion/resolution. In the metric settings, simply exclude the “On Hold” status.

After that, the app will automatically calculate the total active time while ignoring the time the issue spent in On Hold. So the timer will effectively pause when the issue is moved to On Hold and resume when it moves to another status.

This should give you the correct resolution time, excluding the On Hold duration.

You can also try the free trial version of the app to check whether it fully covers your use case.

[BAL GOVIND YADAV]

Thanks for the update!

here are the snaps attached:

Automations rule 1:

set Actual Start : {{now}}

Work Accumulated seconds: 0

Automations rule 2: 

Work item transitioned to ON HOLD

Condition applied: Actual Start is not empty

create variable:

segmentSeconds: {{now.diff(issue.customfield_10008).seconds}}

newTotalSeconds: {{#=}} {{issue.customfield_10433}} + {{segmentSeconds}} {{/}}

edit work items :

Work Accumulated seconds:{{newTotalSeconds}}

Actual start: 0

Automations rule 3: 

Work item transitioned from ON HOLD

edit work item fields:

Actual start: {{now}}

Automations rule 4:

work item transition to Done
create variable:

finalTotalSeconds: {{#if(issue.customfield_10008)}} {{#=}} {{issue.customfield_10433.asNumber}} + {{now.diff(issue.customfield_10008).seconds}} {{/}} {{else}} {{issue.customfield_10433.asNumber}} {{/}}

edit work item:

Work Accumulated Seconds: {{finalTotalSeconds.asNumber}}

Actual end: {{now}}

Actual start: 0

create variable:

days: {{#=}} floor(finalTotalSeconds.asNumber / 86400) {{/}}

remainingAfterDays: {{#=}} finalTotalSeconds.asNumber - (days.asNumber * 86400) {{/}}

hours: {{#=}} floor(remAfterDays.asNumber / 3600) {{/}}

remainingAfterHours: {{#=}} remAfterDays.asNumber - (hours.asNumber * 3600) {{/}}

minutes: {{#=}} floor(remAfterHours.asNumber / 60) {{/}}

edit work item:

Total Resolution Time: {{#if(days.asNumber.gt(0))}}{{days}}d {{/}}{{hours}}h {{minutes}}m

I need the total time when issue is on in progress if the issue is kept on HOLD it should stop calculating time when it is ON HOLD and resume when moved to other status and needs to display total time excluding that on hold duration time.

Thanks and regards
Bal Govind Yadav

[Lukas Maczejka _Appfire_]

Hi @BAL GOVIND YADAV and welcome to the community,

To the best of my knowledge, status durations are not exposed directly, so a pure-automation approach needs to keep a running total of On Hold time itself. The general idea:

• Track when On Hold starts — a rule fires when the issue transitions into On Hold and stamps the current timestamp into a custom field.
• Add to an accumulator when it ends — a rule fires when the issue transitions out of On Hold, calculates how long it was there (now minus the stamped timestamp), and adds that to a running total field.
• Compute active time on resolution — subtract the accumulated On Hold total from the overall elapsed time (resolution date minus created date).

The main edge cases to account for: resolving while still in On Hold, multiple On Hold visits, and rule re-runs. Sharing the audit log as @Trudy Claspill suggested is the right first step to see where your current rule diverges.

Cheers, 

Lukas

[Lukas Maczejka _Appfire_]

Aside from that, if you're open to solutions from the Atlassian Marketplace, the app my team and I are working on, JXL for Jira, gives you this without the automation gymnastics. JXL has a configurable Time in status smart column: pick the statuses to include (e.g. all except On Hold), pick an occurrence mode (sum of all visits), optionally apply a work calendar, and the active time shows up per row.

Disclosure: I work on the team behind JXL.

Cheers,

Lukas

[Trudy Claspill]

Hello @BAL GOVIND YADAV 

Welcome to the Atlassian community.

To help you debug the automation rule please provide the following information:

1. Images showing your entire automation rule.
2. Images showing the details of any step where the full details are not seen in the step bubble in the diagram.
3. Images showing the output for the rule execution from the audit log for a run that did not give you the results you expected. Click the ">" icons next to each message to expand all the details.
4. An explanation of what results you expected versus the actual results you got.