Automation service limits
Jira automation includes a set of service limits to keep your automation rules in check. When rules breach these limits, they're throttled and disabled so they don't affect your Jira instance.
When are rules breaching the limits?
You can recognize when your rules are breaching the limits by the following errors in the audit log:
- Throttled: The audit item status is THROTTLED.
- Detailed description: The audit item includes a more detailed description, for example:
This automation rule spent more than the allowed total time processing in the last day. Maximum allowed processing time over a day is (in minutes):
Automation for Jira has exceeded the allowed maximum number of rule executions in the last hour
A JQL search in this automation rule has exceeded the allowed maximum number of issues to retrieve per search. Only the first issues up to the following limit where processed:
View and set limits by using REST
You can view your current limits and change them by using REST.
View limits
Use the following REST call to check the limits:
https://YOUR_JIRA_INSTANCE_URL/rest/cb-automation/latest/configuration/propertyHere's an example response:
{
"max.processing.time.per.day": "3600",
"rule.rate.per.five.second": "2",
"short.scheduled.interval.issue.limit": "1000",
"max.rules.per.hour": "5000",
"max.issues.per.search": "1000",
"max.queued.items.per.rule": "25000"
}Set limits
To set one of the limits, use the following REST call (the Content-Type must be set to application/json). You can find the properties for each limit in the table below.
PUT https://<your Jira instance url>/rest/cb-automation/latest/configuration/property
{
"key": "max.processing.time.per.day",
"value": "10000"
}Example curl command:
curl -X PUT -H 'Content-type: application/json' \
-d '{"key": "max.rules.per.hour", "value": "10000"}' \
https://your-instance.com/rest/cb-automation/latest/configuration/propertyService limits and their property keys
The following properties control the service limits.
| Limit name | Property key | Default value | Description |
|---|---|---|---|
| JQL searched issues | max.issues.per.search | 1000 | Max number of issues that can be returned by any component that runs a search, for example JQL or Incoming Webhook trigger. |
| Daily processing time | max.processing.time.per.day | 3600 | Max number of seconds a single rule can spend processing, in the last 12 hours. If the limit is breached, the rule is taking too long to execute (might have time-consuming operations), executes too often, or the combination of both. |
| 5 seconds period rule rate | rule.rate.per.five.second | 2 | These two parameters are taken into account when there is a spike of rule execution count in short period of time to decide if rule should be throttled or not. For more info on how this works, see How service limits affect your rules. |
| Max rule execution count per hour | max.rules.per.hour | 5000 | |
| Items queued per rule | max.queued.items.per.rule | 25000 | Indicates how many items can be queued at the same time by a single rule. For more info about queued items, see Queued items below. |
| Total items queued | max.queued.items | 100000 | Indicates how many items can be queued at the same time by all rules. For more info about queued items, see Queued items below. |
| Max loop execution | max.rule.execution.loop.depth | 10 | Controls how loops are detected. A rule (or rules) will be allowed to trigger itself or other rules and create an execution chain up to this limit. If a rule triggers itself immediately, it will be allowed to run 10 times before it's execution is stopped and marked as a LOOP in the audit log. |
| Scheduled JQL issue limit | short.scheduled.interval | 1000 | This limit is used to reduce the interval at which large issue searches can be performed using a scheduled trigger. If a query returns more issues than this limit, the UI shows a warning and only allow schedules of, at most, 4 times in a 24 hour period. This is a soft limit, meaning it only applies when configuring a rule. |
| Branch immediate priority item limit | branch.rule.immediate | 10 | Max number of branch execution that can be executed immediately. If a rule requires more branch executions, they will be stored in the automation queue. Such situation may happen, for example, when a branch component with a JQL query returns more issues than this value. |
| Outgoing webhook timeout | outgoing.webhook.timeout.ms | 30000 | HTTP request timeout for outgoing webhooks (milliseconds). |
| User condition users limit | user.condition.get.users.limit | 50 | Max number of users that can be retrieved from a single role by User Condition. |
| Thread pool size | automation.processing.thread.pool.size.per.node | 6 | Number of threads used to process rules in a queue. By default, it's 6 threads per server (or per node in Data Center), which should be enough for most cases. If your rules execute slowly, try increasing this to 8 threads. As a side effect, this value also defines how many elements from a queue. can be taken in one request by the queue claimer.
|
| Event serializer thread poll per node | automation.event.serializer.pool.size.per.node | 2 | Number of threads used for transforming Jira events into automation events. As such transformation can be expensive, this limit eliminates bottlenecks. The value can't be lower than the default 2 and higher than the number of available cores. |
| Regex timeout | regex.timeout | 30000 | Regex evaluation timeout (milliseconds). This limit protects from poorly optimized regex expressions that could loop for a long time. |
Increasing this value can have the opposite effect and result in worse performance if your database or server can't handle the increased load. Only increase it if you're sure your infrastructure can handle it.How service limits affect your rules
The diagram below shows the algorithm used to decide whether your rules should be executed or throttled. The whole process includes of a set of service limits – if too many are breached, the rule is throttled.
Service limits for queued items
One of the service limits controls the number of items in a queue. This section explains why this limit is important and how easily even simple rules can add lots of items to a queue.
Jira automation uses a rule processing queue to manage the execution of automation rules.
Jira has limited capacity available to serve requests from users in the browser, as well as background services, such as automation rules. To make sure Jira isn't overloaded, rule executions are queued and the number of items processed at the same time is limited. By default, it's 6 concurrent threads per server (or per node in Data Center).
The automation rule builder allows users to configure rules that do just about anything. This can result in rules that are very expensive to run.
Let's consider a scenario with these example issues:
- ABC-120 - Parent development issue with issue type 'Task'
- ABC-121 - Subtask 1
- ABC-122 - Subtask 2
- ABC-123 - Subtask 3
- ABC-124 - Subtask 4
- ABC-125 - Subtask 5
- ABC-130 - Another Parent development issue with issue type 'Task'
- ABC-131 - Subtask 1
- ABC-132 - Subtask 2
- ABC-133 - Subtask 3
- ABC-134 - Subtask 4
- ABC-134 - Subtask 5
Now consider the following rule:
This simple rule would result in 13 individual items in the automation queue. Let's break this down:
- 1 item queued for the initial scheduled trigger execution to run the search
- 2 items queued for the matching parent issues ABC-120 & ABC-130
- Then for each of those items, the related issue's branch queues 5 items each
You can see that these types of rules can quickly add up to a lot of queued items, if for example, the initial scheduled trigger matches a lot of issues, or if the related issue branches match lots of issues (related issue branches can also search for issues by JQL!).
Disabling rules that breach the limits
When a rule adds an excessive number of items to the queue at the end of its execution, it's recorded in the audit log and then the rule is disabled to prevent future executions:
What types of rules can cause this?
Rules with lots of related issue branches, where each related issue branch matches a significant number of issues. For example,
- Scheduled trigger that matches 100 issues
- Related issues branch that matches 50 issues
- Another related issues branch that matches 80 issues
This results in (approximately) 13,000 items (100 * 50 + 100 * 80).
A rule with a lot of related issue branches (to simulate if conditions):
- Trigger: Issue updated
- Related issue branch with JQL: type = Bug that matches 1000 issues
- Related issue branch with JQL: type = Task that matches 500 issues
- Related issue branch with JQL: type = Feature that matches 2000 issues
This results in 3,500 items or more, depending on the number of branches (1000 + 500 + 2000).
Improve your rules so they stay within limits
You can take several steps to make sure your rules stay within the acceptable limits, for example:
Reduce the interval
Reduce the interval at which a scheduled rule is executed. For example, only execute a rule once an hour instead of every 5 minutes.
Limit JQL queries
Use JQL queries that limit the execution to the smallest possible set of issues. This can be achieved in a number of ways:
- Ensure your JQL search is as specific as possible. E.g. don't just search for issues that match
type = Taskif you only care about issues currently 'In Progress'.type = Task and status = "In Progress"would be a better search - Only include issues that have changed since the last time the rule executed by checking the
Only include issues that have changed since the last time this rule executedcheckbox. For many rules, it's perfectly fine to operate only on this small sub-set
Avoid branches for conditional checks
Don't create related issue branches for 'conditional checks'. So the rule above, with many related issue branches checking for type = Bug, type = Task, etc. could be written more efficiently like this:
- Trigger: Issue updated
- Related issue branch with specific JQL to match the issues you're after (related to the trigger issue somehow)
- On this branch use the if/else block to match based on the issue type
In general, the goal is to reduce the overall number of issues a rule fetches, either via the trigger or related issue branches.
For more information on how you can optimize your rules, see Optimize automation rules.