How to calculate cumulative time spent in a specific status (e.g. “Pending”) using Jira Service Mana

[Anurag Chavan]

 Hi Community,

I am looking for a native Jira Service Management (Cloud) solution, using Automation only (no plugins), to calculate how long an issue stays in a specific status — cumulatively.

Use case

An issue can move in and out of the same status multiple times, for example:

Pending → Work in Progress → Pending → Waiting → Pending → Closedhat I need is the

total time spent in “Pending”, including all entries and exits, not just the current duration.

Constraints

• Jira Service Management Cloud

• No marketplace apps / plugins

• Solution should work for many tickets

• Automation-based approach preferred

What I’m trying to achieve

• Capture the timestamp when an issue enters Pending

• When it leaves Pending, calculate the duration of that session

• Add that duration to a cumulative total field

• Ensure the logic works even if the issue re-enters Pending multiple times

If anyone has implemented a similar setup or can share a best-practice automation design, that would be very helpful.

Thanks in advance!

[Marc -Devoteam-]

HI @Anurag Chavan 

Create 3 custom fields, 2 to store the time stamp when entering the status and when leaving.

The 3rd field to store the time difference based on calculation in an automation rule.

You will need to use automation smart values for this, see; https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/ 

So you can set this up with multiple automation rules, at leats 2.

1. rule to set custom field when entering status X
2. rule to set custom field when leaving status X and then calculate the time difference and store this in field 3

[Birkan Yildiz _OBSS_]

Hi  
You can achieve this natively by using automation rules and custom fields. However, while these rules work for basic needs, native automation has significant limitations for enterprise reporting.
Native Jira doesn't support custom calendars. This means it cannot exclude weekends, holidays, or non-working hours, which often leads to highly inflated metrics. Also, automation rules are not retroactive. So, they only begin calculating for issues updated after the rule is created and cannot analyze your existing issue history.
If you need more accurate, retroactive reporting that works on historical data instantly, you might consider Timepiece- Time in Status for Jira.

Disclosure: I am part of the OBSS team, the creators of Timepiece.
 
Best,
Birkan

[Bill Sheboy]

Hi @Anurag Chavan 

While one could create a single automation rule to accumulate the time in the status, it may be unreliable for several reasons.  Please consider these when using a rule for status tracking:

• When rules exceed the service limits, they do not run; thus, the time will be missed
• When Atlassian has an outage preventing rule execution, there is no documentation on which rule triggers / events will run later to "catch up".  Thus, either the time will be missed for tracking or it will be incorrect when the rule eventually runs.
• When someone tampers with / manually changes the custom fields used for the tracking, the calculations could be incorrect.  This could be mitigated by using entity properties rather than custom fields as those are less likely to be manually altered by a person.
• When there are rule errors, the calculations could be incorrect
• Workflows which allow self-transition back to the status could confuse the automation rule if those are not specifically handled

As alternatives, you may want to investigate the marketplace for reporting options, or use the REST API to pull all changelogs into an external database and then parse them to perform the calculations.

Kind regards,
Bill