Automation for Jira allows users to create powerful automation rules using its simple rule builder. With scheduled JQL triggers for example it's possible to setup automation rules that execute over many hundred issues every couple of minutes. These rules can add considerable load to both the Jira instance as well as our cloud service. As a result Jira may experience performance issues for all users of Jira, or automation rules may end up taking a long time to execute in Jira Cloud for all Jira instances using Automation for Jira.
As a result we decided to implement some limits to keep the impact on Jira's performance minimal, and to ensure the cloud service isn't adversely impacted by a single automation rule. We chose these limits such that 99.9% of users will never experience them and only apply to truly exceptional cases.
We currently have the following limits in place:
|Limit||Cloud||Server||Example of how to breach this limit|
|Number of rule components per rule||65||65||Configuring an automation rule with more than 65 conditions and actions.|
|Number of sub-tasks to create per action||100||100||Adding a 'Add sub-task' action that tries to create more than 100 sub-tasks.|
|Number of issues per search||1000||1000**||Configuring a 'Scheduled' trigger with a JQL search that returns more than 1000 issues.|
|Concurrent scheduled rule executions||1||1||A scheduled rule that takes longer than 5 minutes to execute, scheduled every 5 mins. This limit will only allow a single concurrent execution of this rule.|
|Number of items queued by rule||5000||25000||See our KB on the queued item limit for more information.|
|Processing time limits|
|Daily processing time||120min||120min||Setup a rule that executes every 5 mins where each execution on average takes longer than 5 seconds (in cloud). This could be the case if your rule talks to slow external systems for example.|
|Hourly processing time||40min||100min||Configure several rules that listen for issue events and carry out a bulk operation that executes these rules. This limit will only trigger if there are more than 2000 rule executions per hour in cloud and more than 5000 rule executions per hour in server)|
** In server this number is derived from the *jira.search.views.default.max *configuration property which can be configured and limits the number of issues returned per search globally in Jira.
If you're running the latest version of Automation for Jira, then you can use the Service limit breached trigger to setup an automation rule to send out notifications when you are about to breach one of the Processing time limits above.
When a rule breaches its limit, the audit log will contain more details:
Based on the details provided in the audit log you can take several steps to ensure your rules fall below the acceptable limits:
- Reduce the interval at which a scheduled rule executes. For example, only execute a rule every hour instead of every 5 minutes.
- Reduce the number of issues, by restricting your JQL query to only
the issues you care about. E.g. check that the
updatedtime of the issue is within a certain range (like
updated > -1wto include only last week's issues).
- Split your automation rule across several rules if you need more components per rule.
- For large once off operations that need to edit several 1000 issues, use Jira's bulk change functionality.
Increasing service limits
In cloud we will determine on a case by case basis if these limits should be increased. Please contact support and provide us with more details about your automation rules and use case.
For server we will add an administration UI in future allowing global administrators to set values for some of the above limits. For now you can change these values via a REST API.