Which consumes less JIRA resources: Script Listener or Automation Rule? Edited

I currently have 94 active automation rules that sometimes (depending on peak days) send "service limit" alerts wherein rule execution were "throttled".  While Code Barrel has recommendation on how to increase Automation Service Limits, (https://codebarrel.atlassian.net/wiki/spaces/AUTO4J/pages/54200905/How+to+increase+Automation+service+limits+to+prevent+loop+detection+in+JIRA+Server?showComments=true&showCommentArea=true), I am considering using Adaptavist Scriptrunner's Script Listeners to replace some of our Automation Rules.  "Fast-track transition an issue" is an ideal listener in lieu of more than half of our Automation Rules that update ticket Status based on user comments.

Before doing this however, I would like to be certain that I will I be saving JIRA resources with this alternative approach.  Which one consumes less memory, an Event Listener or Automation Rule?

Thanks for your help.

2 answers

0 votes


What do you mean by Automation Rule? Is it a service desk rule or from a plugin? If from a plugin then from which one?

Hi Alexey - Automation Rule from Code Barrel's Automation Lite for JIRA.


I am 90% sure that listener will be faster. In my opinion  the biggest problem about automation lite is that you need to define conditions by jql query.  If your jql query begins to take long time for execution then you get into trouble. If your instance is small then everything is fine.  If your instance grows then you may have problems with performance. Just do not select issues from jql queries in scriptrunner listener or you will have the same problem.  Or avoid selecting from jql queries as much as possible. I do not want to tell that automation lite is bad. I several times recommended it.  Just each plugin must be used wisely. Or you can try to optimize your jql conditions in automation lite. 

the biggest problem about automation lite is that you need to define conditions by jql query.

In Automation for Jira you don't need definite issue conditions / triggers with JQL (although you can).

If the rules are being triggered off an action like "Comment" or "Edit" the app runs as an event listener for that particular issue, not as a JQL search.

In "Conditions" you can match by the field values directly, which also avoids the need to use JQL (although that option is also possible)

You're right though in that if you're optimising for performance, avoid using excessive JQL queries in your rules will be beneficial.

0 votes

Hey there Doods,

Just a quick one on the limits. They're there to protect users from accidentally overloading their Jira instance. This is especially important since Project admins can configure rules as well. As global-admins, you can loosen these limits as you need to.

On the Event listener VS Automation rule side, our automation rules do run as event listeners, which then queues actions that is needed to run in the background. You can configure this to run synchronously if you want (this will in effect work like running an "Event Listener"). However, running all transformations in an event listener has the potentially to slow down over all Jira performance since this executes synchronously (this is why we background the updates by default). We try to be careful with the health of your core Jira instance as a top priority. 

Definitely try out which one works better for your case though, and drop us a line if you need any help.


Mark C

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,967 views 19 22
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you