Forums

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

In Status Since and Days In Status

Ashraf B November 3, 2025

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

 

 

 

5 answers

3 votes
Marc - Devoteam
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.
November 4, 2025

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.

3 votes
Paul Glantschnig - JXL
Contributor
November 4, 2025

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:

time-in-status-v2.gif

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

1 vote
Alina Kurinna _SaaSJet_
Atlassian Partner
November 4, 2025

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:

  • Define SLA goals per status, assignee, priority, or any custom field.
  • Set up Start, Pause, and Stop conditions – for example, the SLA can start when the issue enters a status like “In Progress” and stop when it leaves.
  • View precise time spent in each status automatically – including paused or excluded times.
  • Avoid hitting automation limits: the app works outside of Atlassian’s automation engine.

What you can set up:

  • SLA goal: Status = In Progress
  • Start condition: When Work Item transitions to “In Progress”
  • Pause condition (optional): e.g. “Waiting for Customer”
  • Stop condition: When it leaves “In Progress”
  • You’ll see the actual time spent, even for ongoing tickets.
  • You can also track remaining vs elapsed time, create dashboards with SLA performance, and generate automated SLA reports filtered by team, priority, service type, etc.

SLA-1.png

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.

SLA-2.png

SLA-3.png

Let me know if you have any questions – happy to help!

Regards!

1 vote
Valerie Knapp
Community Champion
November 4, 2025

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

Kristian Walker _Adaptavist_
Community Champion
November 4, 2025

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. 

Like Valerie Knapp likes this
0 votes
Birkan Yildiz _OBSS_
Atlassian Partner
November 4, 2025

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.

image (34).png

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.

image (35).png

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.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events