How to calculate Jira time in status and roll it up to the Epic level?

[Lira Martynenko]

Hello everyone,

I’m trying to calculate Jira time in status across specific status groups and store the total duration in a custom field.

I created a field to capture how long an issue stays in selected statuses. I attempted to use multiple automation rules, but the results weren’t reliable, and the setup became overly complicated. Now I’m considering using ScriptRunner, but I’m not sure how to approach it correctly.

Ultimately, I need to aggregate Jira time in status across several issues and roll it up to the epic or initiative level as a sum of all related tasks and subtasks.

Has anyone implemented something similar? I’d really appreciate your advice.

[John Funk]

Hi Lira - Welcome to the Atlassian Community!

This article might specify other fields, but it should work in your case as well by just subbing out the example with your field name.

https://community.atlassian.com/t5/Jira-articles/How-Can-I-Sum-Up-Multiple-Issues-into-a-Parent-Number-Field/ba-p/2882712

[Lira Martynenko]

Hi John,

Thank you so much for the warm welcome and for sharing the article - I really appreciate it!

I’ll review it and try adapting the example to my field name as you suggested. It looks very relevant to what I’m trying to achieve.

If I run into any issues while configuring it, I’ll follow up here. Thanks again for your help!

[John Funk]

You are very welcome. Let us know how it goes!

[John Funk]

Hey  @Lira Martynenko - any update? 

[Iryna Krutko_Broken Build]

Hi @Lira Martynenko 

The problem: You need to track the total time issues spend in specific status groups and then aggregate (sum up) that time at the epic or initiative level across all child tasks - without relying on complex ScriptRunner scripts or fragile automations.

The solution: The Time in Status chart in Agile Cycle Time Charts does exactly this out of the box. It measures how long each issue stays in each workflow status, and you can define custom In Progress and Waiting status groups to match your process.

The chart automatically sums time across all issues in scope, and the Issue list lets you group results by Epic Link / Parent - so you can see aggregated time per epic without any custom fields or scripting.

You can also drill down from status group → individual status → issue → assignee for full transparency.

For a hands-on look, here's an interactive, clickable demo showing how the chart works: Time in Status Report Example. There's also an Epic Time in Status chart example that demonstrates the epic-level aggregation you're after.

Hope this helps - feel free to follow up if you have any questions about the setup!

[Bartek Szajkowski _ Orbiscend OU]

Hello @Lira Martynenko 

I'm Bartek from Orbiscend OU.
If you are open for third-party app, to find solution of your request, I could recommend to check functions provide by ARGON ARGON Powerful JQL Search 

The timeInStatus and timeExpression function allows you to find issues that have spent a specific amount of time in a given status. This is useful for tracking how long issues remain in particular workflow states.

 

When creating a Time in Status custom field, you can select multiple statuses at once — Argon will automatically accumulate the total time spent across all of them. No automation rules or scripting required.

 

Also use the childrenOf function to find all child issues under an epic, then filter by their accumulated cycle time. You can also query from the parent's perspective using parentOf.

I hope that with my hints, you will find the best solution for yourself.
Greetings
Bartek (Orbiscend OU)

[Danut M _StonikByte_]

Hi @Lira Martynenko,

Welcome to Atlassian Community!

This is quite advanced functionality and would be difficult to achieve, even with the help of plugins. Such calculations are complex to implement, and the overall process is prone to errors.

Since Jira does not offer this functionality out of the box, I recommend exploring the apps on Atlassian Marketplace that offers a report or gadget that can perform these calculations and present the data in a clear, user-friendly way.

If you consider using an app, I would recommend trying the Time in Status gadget offered by our Great Gadgets app.

Time in Status for individual issues - the gadget can calculate the average or total time in each status for the issues in a filter. 

On its Data tab the gadget will display a table with all the issues and their time in every workflow status.

Group time in status data by Epic - the gadget allows you to group data by a field, such as Epic Link, which will aggregate the data by epic

On its Data tab, it will display the data grouped by Epic.

Hope this helps.

Danut. 

[Petru Simion _Simitech Ltd__]

Hi @Lira Martynenko ,

Yes — this is a very common requirement, and trying to solve it with multiple automation rules usually becomes unreliable and overly complex (especially when handling reopens, loops, workflow differences, and roll-ups).

Instead of building and maintaining ScriptRunner logic, you can achieve this much more cleanly with Time in Status Reporter for Jira (built by our team).

---

✅ Why this fits your use case

The app allows you to:

• Create Status Groups

• Calculate total time spent across multiple statuses

• Define different statuses per issue type within the same group

• Roll up results to Epic / Initiative level

• Apply working calendars (business hours + holidays)

• Configure groups and calendars globally or per user

---

🔹 Status Groups (Core Concept)

In your case, you could create a group called Lead Time.

Example configuration:

For Story:

• To Do

• Open

• In Progress

• Backlog

For Bug:

• Open

• Backlog

• In Progress

• Reopened

---

💡 Why different statuses per issue type are critical

Workflows differ between issue types.

• Bugs often include Reopen, Stories may not

• Some statuses exist only in specific workflows

• Some teams treat Backlog differently per issue type

If you forced the same statuses for all issue types, you would either:

• Miss time for some issues

• Include irrelevant statuses

• Or require workflow changes

By allowing different statuses inside the same group per issue type, the calculation remains accurate regardless of workflow differences. This is especially important in larger organizations where workflows evolve over time.

---

🔹 Global vs User Groups

Status Groups can be configured in two ways:

• Global Groups – created by a Jira admin and available company-wide

• User Groups – created by individual users for personal reporting needs

This is very useful because:

• Leadership can define standard metrics like Lead Time or Cycle Time globally

• Teams or individuals can create custom analytical groups without impacting others

You get governance + flexibility at the same time.

---

🔹 Calendars (Business Hours & Holidays)

The app also includes Calendars, which significantly improves accuracy.

Calendars can be:

• Global (defined by admin for the whole organization)

• User-level (custom working schedule per user)

Each calendar allows you to define:

• Working days (e.g., Mon–Fri)

• Time slots per day (e.g., 09:00–18:00)

• Multiple time windows if needed

• Company holidays

This means time is calculated according to actual business hours, not just raw 24/7 elapsed time.

For example:

• Nights excluded

• Weekends excluded

• Public holidays excluded

• Regional schedules supported

This is extremely important for realistic SLA, Lead Time, and Cycle Time calculations — especially across global teams.

---

🔹 How the Result Looks

Once configured, your group (e.g., Lead Time) appears as a calculated column in reports.

You’ll see:

• Total duration per issue

• Accurate handling of status loops and reopens

• History-based recalculation

• Calendar-adjusted time (if applied)

---

🔹 Epic / Initiative Roll-up

You can then:

• Filter by Epic Link / Parent

• Aggregate total Lead Time across related issues

• Sum results at Epic or Initiative level

• Export data for further reporting

This avoids:

• Manual custom field updates

• Automation race conditions

• ScriptRunner performance overhead

• Recalculation inconsistencies

---

🔹 Why Automation / ScriptRunner Become Complex

To implement this manually, you would need to:

• Track entry/exit timestamps for each status

• Handle loops and reopens

• Handle bulk moves

• Handle workflow edits

• Recalculate if issue type changes

• Manage business-hour logic

• Roll up to parent levels

That becomes heavy, fragile, and hard to maintain.

A history-based calculation engine with status grouping and calendars solves all of that cleanly.

---

Summary

If your goal is to:

• Calculate time across specific status groups

• Support different workflows per issue type

• Apply business-hour calendars with holidays

• Define metrics globally or per user

• Roll up values to Epic / Initiative

Then Time in Status Reporter for Jira will be significantly simpler and more reliable than building a custom ScriptRunner or automation-based solution.

Regards, 

Petru

[Birkan Yildiz _OBSS_]

Hey @Lira Martynenko 
First, welcome to the Community!

You are definitely not alone in this. Trying to calculate Time in Status and roll it up to the Epic level using Jira Automation is notoriously difficult and unreliable.

For this specific use case, a dedicated reporting app is a much simpler approach. Full disclosure, I'm on the team that makes Timepiece - Time in Status for Jira, and it handles this exact scenario out of the box without any scripting.

Instead of trying to store these values in custom fields, you can generate a Status Duration report and use two built-in features to get exactly what you need:

Epic Roll-up: You can set the report options to show the SUM of values across issues and Group By Epic Link. This automatically calculates the total time of all child tasks and subtasks and rolls them up into a single row for each Epic.

Status Groups (Consolidated Columns): You can group your specific statuses together into a single custom column. This instantly gives you the total duration for that specific phase of your workflow.

The best part is that it reads your existing Jira history, so it works for all your past and current data immediately upon installation.

You can check Timepiece - Time in Status for Jira on the Atlassian Marketplace. Hope this saves you from having to write and maintain custom scripts!

Best,
Birkan