Best way to write Scriptrunner event listeners, 1 listener vs many listeners Edited

I'd like to have different scripts to trigger depending on which field is changed. Is it better to handle all update event in one script, or to have many scripts, in my example 1 per field?

I am more looking in the impact on the Jira server performance rather than coding best practices.

1 answer

1 accepted

Hey JS!

If you are wanting multiple things to happen upon the firing of a single event, say an IssueUpdatedEvent, I'd suggest doing it all in one listener.

Generally it wouldn't make much of a difference, but with multiple listeners that fire off of the same event, there is no way of knowing which one is going to run first. So by putting everything in a single listener you are saving yourself the headache of not knowing in what order they are going to execute.

So, although you lose some organization and are probably going against good coding practice, you are saving yourself money that would inevitably be spent on Advil.

Happy coding!


Hi Aidan, 

thanks for your answer! I see your point of deterministic execution of handlers and I'll keep that in mind, but I am more interested in the performance hit of having multiple listeners vs 1. I think you hinted that it does not really have a significant impact but I just want to make sure!

If there is no big hit, I could have a hybrid solution where handler that needs to be performed in a specific order resides in 1 script and have the other handlers in different listeners.



So really it just comes down to your use-case. It all depends on what you're wanting to do when the event fires.

For example, if you are checking for a changed field, it may be slightly more efficient to put all of your code into a single listener so that you don't have to keep repeating the same code and re-grabbing components. Listeners that do about the same thing, I would keep together.

Another case is if maybe your listener needs to access a REST Endpoint or something else external. That brings into play latency and a whole bunch of other factors. In a case like that, I would also recommend just a single listener so that you don't have to re-contact that external process more than once.

But honestly you just have to look at your use-case and make a judgement call. If you think you are creating listeners that are pretty extraneous and can be combined, combine them. Otherwise, I wouldn't worry about it all too much as the difference between the two methods is most likely negligible.

Does that make sense? :)

Yes definitely, you provided a good perspective with the cost of accessing resources multiple times if there are multiple scripts at play.

I'll definitely keep that in mind when developing solutions.

Thanks for your help!


Anytime! :)

Could you go ahead and accept this answer to help other users who have similar questions find it?

Don't be shy with any other questions if you have them!


good catch, I voted for your answer but did not see the accept check box! Done!

Haha no worries :D

And if you need help developing a listener or any other ScripRunner related Script, we have tons of examples in our documentation.

Goodluck in your SR adventures to come! :] 

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published Jul 10, 2018 in Marketplace Apps

If you’re an Atlassian app developer, you’ll want to know about Atlas Camp!

This September 6-7, hundreds of Atlassian App developers will flock to Barcelona Spain to build skills, discover product roadmaps, meet face-to-face with the Atlassian team, and learn how to extend t...

182 views 0 4
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