For analysis purposes, I’d like to track how much time (preferably in minutes or hours) an issue spends in a particular status.
I’m aware that there are native Jira apps available for this purpose. However, my organization currently prioritizes simple and free solutions.
From my understanding, it should be possible to achieve this by:
Time in Production)I’ve tried to implement the following automation, but it doesn’t seem to work as expected:
{{Time in Production.diff(now).minutes}}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.
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
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:
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You can check it out on the Atlassian Marketplace. Hope this helps you get the data you need!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
Production Entry Time: Create a Date Time Picker custom field.
Time in Production: Create a Number custom field (this will store the total minutes).
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}}
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.