Has anyone hit a Jira automation cap/soft cap?

[Chris Thomas]

Just a question about Cloud automation.

I have a Jira project admin who will be releasing a project automation rule that could run 4 times per ticket and traffic looks to be around 1000 issues per day.

If they added more automations could our cloud instance performance start degrading?

We are on Pro and not using global automations to this level so not worried about caps, just performance at some point.

[Leonard Hussey · Accepted solution]

Hey Chris,

I lead a JIRA cloud project that is 99% held together by automations. We're on Pro, too.

Automations running all day long: reacting on creation, on changes, comments, scheduled hourly, bi-hourly, daily, webhooks, etc. Multiple automations running per single issue update. All in parallel. Non-global.

I've rarely noticed any degradation. There are very sporadic instances in which the automation reacts "late" to a change... a couple times even 10 min after a change. But it is rare and I've concluded it is caused by some transient infra issue at Atlassian level.

The only time in which I see a bit of consistent sluggishness (but non impacting) is when some broad-scope data correction (updates) is being done over several tickets. I'm talking about bulk tasks touching 1000s of tickets at a time.

And: I'd say that of more concern are the automations race conditions. Since they run in parallel, some automations can clash with each other if working over same fields. For e.g. several automations that run in parallel and write labels.

Hope this helps.

[Leonard Hussey]

And I'd like to add that there are time limitations in automations with respect to accumulated run time.

IIRC: 3600 sec per each 12h. If hit, the automation will throttle.

Unsure how complex your automation will be. But if you hit the limit, I guess you'll have to split it into 2 or more where the JQL in use ensures that the tickets touched by each do not repeat in the other automations.

This you can only know once you run it.

Thanks.

[W Bot]

Hey All,

I've got a LOT of automations that frequently act to update an aspect of an issue when some things change, and generally things are well behaved (I'm on Premium cloud).

I do run into issues in a couple of cases:  bulk updates that trigger a bunch of issues, you can hit your hourly limit per rule (each rule has a cap on executions in an hour period) in this case.

It can also happen if you have a lot of automations that trigger further automations.

For example, I have a multi-value field that when one of the values is selected, it triggers a specific automation, then removes that value at the end.

This is super clever and saves custom fields, but when I update that field with a value like "run automation A", if rules B/C/D/E/F all look at that "field change" event for that field, they ALL run trying to see if they should do something.  So one update triggers 6 rules to run, then run 6 more times when the value is removed.  Now 5 of those rules are basically "something happened, but condition not true, end" but it's still noise.

Overall it's tolerable, but sometimes (especially early) I hit the limits.

If you think in executions per hour per rule, that will help.

I'd use the execution controls like "issue operation type" as well to your advantage to keep this down to whatever is necessary. 

Build it as tight as you can from the beginning to give you room to grow.

I should note, that I don't see any performance hits on this in jira operations even when it's full blast, although sometimes the external API gets a little busy.

The biggest bummer is if a rule get's throttled, it DUMPS executions past that point and they will never run for those issues (unless triggered again).  This has necessitated scheduled housekeeping rules to do some checks and cleanups in some cases, or clever bulk updates.

Again, hopefully you won't hit these barriers like I have, and this advice helps avoid them or understand them! 

Best!

[Paul Benario]

Super interested in this question/answer, since we may be in the same boat.