Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Automation rule to calculate the 'time in status X'

Isabell Barsamian October 27, 2025

For analysis purposes, I’d like to track how much time (preferably in minutes or hours) an issue spends in a particular status.

Context:

I’m aware that there are native Jira apps available for this purpose. However, my organization currently prioritizes simple and free solutions.

Approach:

From my understanding, it should be possible to achieve this by:

  1. Creating a custom field (e.g. Time in Production)
  2. Setting up an automation rule using smart value variables to calculate the time spent in a specific status.

Current Challenge:

I’ve tried to implement the following automation, but it doesn’t seem to work as expected:

  • Trigger: Issue transitions from status “Production” to any other status
  • Action 1: Create smart value variable
    {{Time in Production.diff(now).minutes}}
  • Action 2: Edit issue → set custom field Time in Production to
    {{Time in Production.diff(now).minutes}}

As you can probably tell, I’m fairly new to Jira automation. I’d really appreciate any input or suggestions to help me improve this setup and make it work.

5 answers

0 votes
Isabell Barsamian October 27, 2025

Dear  @Gor Greyan 

unfortunately, the suggested approach didn't work and I'm not sure why.

 

@John D Patton  There seems to be an issue with the {{issue."Time in Production".withDefault(0).plus(issue."Production Entry Time".diff(now).minutes)}}

Jira won't accept it as an acceptable variable. Do you have an idea why that might be?

Thank you so, so much for your input! I truly appreciate it!

Best regards

0 votes
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 27, 2025

Hi @Isabell Barsamian 

Short answer: a limited, rule approach may be used, and it definitely has accuracy risks.

 

As others have described, an automation rule-based approach usually needs two rules to measure the time a work item has been in a status:

  1. one to start the clock upon entry to the status
  2. one to stop the clock upon exit, and to accumulate the time to a total

Both of those rules depend upon rules running when the event happens.  That is not always the case, as Atlassian outages and delays in automation processing could add days to the total time, if they ever run.  (There is no documentation on which rules will run, by event type, to "catch up" after an automation outage.)  A more reliable, and much more complex method, is to read the changelog history for each work item and accumulate the time from the transition entries. 

Although a team can build an app to read all the changelog entries and do so, that approach cannot be done in an automation rule due to looping and endpoint data paging limits.  Thus, many just use the built-in, Atlassian interpretation of a Control Chart or use a marketplace app / addon.  I wanted to share those risks so your team may watch for them when they happen.

 

Kind regards,
Bill

0 votes
Birkan Yildiz _OBSS_
Atlassian Partner
October 27, 2025

Hey @Isabell Barsamian 

 

I know you're looking for a free solution, but as you've started to discover, the native automation approach has a few key challenges:

It isn't retroactive, so it won't work for your past issues.

It doesn't easily handle cases where an issue enters the same status more than once.

Most importantly, it calculates based on a 24/7 calendar time, including nights and weekends, which can make your data inaccurate.

For a much simpler and more accurate solution that avoids these issues, you might consider a Marketplace app.

Full disclosure, I'm on the team that makes Timepiece - Time in Status for Jira, and it's designed to do this automatically without any complex setup.

Our Status Duration report instantly shows you how much time (in minutes, hours, or days) an issue has spent in any particular status, including "Production".

The key benefits are:

It's Easy & Fast: There are no automation rules to configure.

It's Retroactive: It works for all your past issues immediately after installation.

It's Accurate: It correctly calculates the total time even if an issue enters the same status multiple times, and you can use custom calendars to exclude non-working hours.

 Screenshot 2025-10-27 172355.png

You can check it out on the Atlassian Marketplace. Hope this helps you get the data you need!

0 votes
John D Patton
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 27, 2025

Hello Isabell,

The issue with your current setup is that the rule only fires when the issue leaves the status, so it doesn't have a "start time" to compare against.

A simple and reliable way to fix this might be to use a helper field and a second automation rule to capture that start time.

Required Setup

  1. Production Entry Time: Create a Date Time Picker custom field.

  2. Time in Production: Create a Number custom field (this will store the total minutes).

Rule 1: Log Entry Time 

This rule captures the moment the issue enters the status.

  • Trigger: Issue transitioned

    • To status: "Production"

  • Action: Edit issue

    • Field to edit: Production Entry Time

    • Value: {{now}}

Rule 2: Calculate and Store Total Time

This rule calculates the time spent when the issue leaves the status.

  • Trigger: Issue transitioned

    • From status: "Production"

  • Action: Edit issue

    • Field to edit: Time in Production

    • Value: {{issue."Time in Production".withDefault(0).plus(issue."Production Entry Time".diff(now).minutes)}}


This two-rule system will now work as you expect.

  • Rule 1 logs the start time.

  • Rule 2 uses smart values to calculate the difference in minutes and adds it to the Time in Production field.

  • Using .withDefault(0) ensures the math works even if the field is empty, which allows the rule to keep adding time if the issue moves in and out of "Production" multiple times.

I hope this helps!

0 votes
Gor Greyan
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 27, 2025

Hi @Isabell Barsamian

Welcome to the Atlassian Community and thanks for the question!

The main issue is that it .diff() needs two date/time values, but your “Time in Production” field is a number. So Jira can’t subtract now from it.

So, to achive this, you need 2 fields.

1. Entered Production - Date Time Field

2. Time in Production(minutes) - Number field

Automation 1:
Trigger: --> Issue Transitioned to Status Production (or what you want)

Edit field --> Entered Production set {{now}}

Automation 2:
Trigger: Issue Transitioned from status Production

Edit field --> Time in Production(minutes) set to {{#=}}
{{issue."Time in Production (minutes)"}} + {{now.diff(issue."Entered Production").minutes}}
{{/}}

Please let me know if this works or not.

Suggest an answer

Log in or Sign up to answer