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

[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