Hi Everyone,
I have created a couple of automations in connection with "Days In Status" information requirement
Automation #1. At every WorkItem transition, I am capturing the date on which the WorkItem was moved to the said Status - I'm storing this value in a CustomField (say InStatusSince). Simultaneously I'm setting the value of another CustomField (DaysInStatus) to 0.
Automation #2. Everyday at 8:30 hrs, I have scheduled another Automation that calculates the days from "InStatusSince" and stores the value in DaysInStatus. Needless to say, this Rule runs only once a day for all the Open WorkItems.
Considering the no. of Open WorkItems and continuous communication between Agent and Customer, the Automation #1 Rule runs very frequently, around 300 times a day.
Now, with Atlassian's Rule Run limit of 5,000 per month, it's not possible to let Automation #1 run because this Rule itself will need approx. 9,000 executions. In other words, with the current pace, my Rule Run limit of 5,000 will get exhausted within a week, because other Automations also consume the executions.
Please suggest if there's a way to optimize / override the Automation #1 with any other, or any other feature / field / automation to achieve the said functionality of DaysInStatus...
Best regards,
Ashraf B
Hi @Ashraf B
I would change the trigger of rule 1 to a scheduled one and run maybe every couple of hours or look at 3rd party option from the marketplace, like Time in Status
Other question on this, why is this information important, wouldn't it be better to start using SLA's, instead of the current solution.
If you use this information for internal usage, you can hide the SLA times from the issue on the portal and use the "dummy" SLA for measuring.
Hi @Ashraf B ,
if you're open to solutions from the Atlassian Marketplace, you'll have options available. E.g., you may want to check out the app that my team and I are working on: JXL for Jira.
JXL is a full-fledged spreadsheet/table view for your issues that allows viewing, inline-editing, sorting, and filtering by all your issue fields, much like you’d do in e.g. Excel or Google Sheets.
It also comes with a long list of so-called history columns that aren't natively available, including the time in [status], time between [status] and [status], and many, many more.
Further information can be found here.
Just as an example, you can build a view like e.g. this in just a couple of clicks:
As you can see above, you can easily sort and filter by your history columns, and also use them across JXL's advanced features, such as support for (configurable) issue hierarchies, issue grouping by any issue field(s), sum-ups, or conditional formatting. Of course, you can also export your data to Excel or CSV in just two clicks.
Any questions just let me know,
Best regards,
Paul
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Ashraf B
I understand why you set up automation rules to calculate Days in Status – but with the number of status transitions happening every day, it’s very easy to hit Jira’s monthly automation execution limit.
I’d actually recommend avoiding this path altogether and letting Jira track this time automatically through SLA logic.
If you're open to using Marketplace apps, I’d recommend trying SLA Time and Report for Jira, developed by our team at SaaSJet. It offers a more efficient and scalable alternative to daily automation rules and complex field calculations.
Why this app can help:
Instead of custom field tricks and daily scheduled rules, you can:
What you can set up:
Bonus for you:
You’ll get centralized SLA data across your entire project, which is especially useful if you're managing a large volume of tickets and need visibility into progress delays, bottlenecks, or escalations – without burning through your monthly rule quota.
Let me know if you have any questions – happy to help!
Regards!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Ashraf B , thanks for your post.
I have been in a similar situation, trying to calculate the SLA performance (basically) using a workaround.
Do you have any budget available for this solution? I ask because I think you could use a ScriptRunner Listener - https://www.scriptrunnerhq.com/help/example-scripts/calculate-custom-field-on-issue-update-cloud
Or the app Time to SLA might help you https://marketplace.atlassian.com/apps/1211843/time-to-sla?hosting=cloud&tab=overview
Otherwise, I think you are going to have to accept also to run Rule 1 less frequently, you could change it to be scheduled every few hours, as opposed to being called on every transition. Do you think that would work?
Best wishes
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you use ScriptRunner for Jira Cloud the example here shows how to create a calculated field which shows how long an issue has been in its current status.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey @Ashraf B ,
You've run into one of the most common and frustrating challenges with that approach: the Jira Automation run limits. When you have a busy project, those rule executions disappear quickly.
For this exact problem, a dedicated reporting app is often a simpler and more sustainable solution.
Full disclosure, I'm on the team that makes Timepiece - Time in Status for Jira, and it's designed to solve this without using any of your automation credits.
Instead of using custom fields and rules to store the value, Timepiece calculates "Days In Status" instantly from your existing issue history whenever you run a report. Our Status Duration report will show you how long every issue has been in its current status (e.g., In Progress, To Do), which is the exact data you're trying to get with your "Days In Status" field.
This approach has a few key benefits:
It doesn't use automation credits: Timepiece has its own reporting engine, so it doesn't consume any of your 5,000 monthly automation runs.
It's retroactive: It works for all your past issues immediately, not just new ones created after you build the rules.
It's more accurate: You can use custom calendars to calculate time based on your business hours (e.g., excluding nights, weekends and even lunch time), which is much more accurate than a 24/7 calculation.
I see you also built a scheduled rule to get a daily update. You can do that in Timepiece as well. If you want these reports delivered regularly, you can use our Scheduled Reports feature to have the system automatically email (or Slack and MS Teams) them to you or your team at any interval you choose.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.