Service limits

Ensuring your Jira Server instance is running smoothly is the responsibility of any good Jira admin. With our service limits you're covered and 99.9% of you will never experience these limits, they only apply to truly exceptional cases.

Limit Cloud Server Example of how to breach this limit
Components per rule 65 65 More than 65 conditions, branches and actions for one rule
New sub-tasks per action 100 100 Triggers the creation of over 100 sub-tasks
Issues searched 1000 1000* A scheduled JQL search that isn't streamlined enough and returns more than 1000 issues.

* In server, this number is derived from the  jira.search.views.default.max configuration property. This can be configured and limits the number of issues returned per search globally in Jira.
Concurrent scheduled rule executions 1 1 A scheduled rule that takes longer than 5 minutes to execute, scheduled every 5 mins. Only allow a single concurrent execution of this rule is allowed.
Items queued by rule 5000 25000 See the section below on queued items limit for more information.
Items queued globally 50000 100000 Similar to queued items per rule but applies to rules in progress across your Jira instance globally.
Daily processing time 120 min 120 min A rule executes every 5 mins and each execution 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 40 min 100 min Configure several rules that listen for issue events and carry out a bulk operation that executes these rules. This limit only triggers if there are more than 2000 rule executions per hour in cloud and more than 5000 rule executions per hour in server)
Loop detection 10 10 This controls how many times a rule can trigger itself (or other rules) in quick succession before execution is stopped and marked as a LOOP.

If you're running the latest version of Automation for Jira, 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.

Breaching limits

If you see errors like these in your audit log, you're hitting limits:

  • The audit item status is THROTTLED
  • The audit item contains one of:
    • 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:

When a rule breaches its limit, the audit log contains more details:

service limits

Based on the details provided in the audit log you can take several steps to ensure your rules fall below the acceptable limits, such as:

  • Reduce the interval at which a scheduled rule executes. For example, only execute a rule every hour instead of every 5 minutes.
  • Restrict your JQL query to only search for the issues you care about. E.g. check that the updated time of the issue is within a certain range (like updated > -1w to include only last week's issues).
  • Split your automation rule across several rules if you need more components per rule.
  • For large, one-off operations that need to edit several thousands of issues, use Jira's bulk change functionality.

Increasing service limits

In cloud, increasing limits is determined on a case by case basis. Please contact support and provide us with more details about your automation rules and use case.

For server, you can change these values via a REST API.

Use a REST call to increase limits

First, find out what your current limits are using this HTTP REST call:

https://YOUR_JIRA_INSTANCE_URL/rest/cb-automation/latest/configuration/property:

{
    "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"
}

Lets break these down:

Property Description
max.processing.time.per.day This is the maximum number of seconds a single rule can spend processing in the last 24hr period. That is, if a rule takes 1 min to execute on average and it executes 60 times in a 24 hour limit, then this rule would be throttled.
rule.rate.per.five.second
max.rules.per.hour
These control how many rules can be processed. These work like this:
  • If more executions happened in the last 5 seconds than specified by rule.rate.per.five.second, check if the max per hour limits have been reached on this tenant.

This guarantees that if there's spikes of activity, they'll be throttled. However, if after this spike, activity returns to normal and rules trickle in slowly, then they execute again immediately.

For example, you have rule A triggered 10 times in the last 5 seconds: how many times did all rules trigger in the last hour is checked. If this exceeds 5000 for the instance, then this rule execution is throttled.

max.issues.per.search This controls how many issues are processed in total by any trigger that runs a search (e.g. JQL or Incoming Webhook trigger). Defaults to jira.search.views.default.max configuration property which can be configured separately.
short.scheduled.interval.issue.limit 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.
automation.processing.thread.pool .size.per.node This one is a bit different from properties above. It defines the number of threads processing rules off the queue in Jira server. By default, this is 4 threads per server (or per node in data center). Generally this should be plenty for most instances. If you are seeing slow rule executions, you may want to increase this to 8 threads.

⚠️ Warning: Increasing this value can have the opposite effect, and result in worse performance if your DB or app server can't handle the increased load. Only increase this value if you are sure your infrastructure can handle it.

max.queued.items.per.rule See queued service limits for more information.
max.queued.items Similar to max.queued.items.per.rule but applies globally for your Jira instance across all automation rules currently in progress.
max.rule.execution.loop.depth This 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. By default this is 10. So in the simplest case, if you have a rule that triggers itself immediately, then it will be allowed to run 10 times before it's execution is stopped and marked as a LOOP in the audit log.

To set one of these properties, please use this REST call (the Content-Type must be set to application/json) :

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/property

More tips and suggestions are in how to optimize your Automation for Jira rules for best performance.

Queued items service limit

Automation for Jira uses a rule processing queue to manage the execution of automation rules in your instance. Jira has limited capacity available to serve requests from users in the browser, as well as executing 'background' services such as automation rules. To ensure Jira isn't overloaded rendering it unresponsive, automation rule executions are queued and the number of items processed off the queue in parallel are limited. By default, in Cloud only 8 items are processed in parallel per Jira host, and 6 concurrent threads in server (per node for Data Center configurations).

The automation rule builder is very powerful and allows users to configure rules that do just about anything. This can result in rules that are very expensive to run. Lets consider a particular 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:

Sample rule

This simple rule, results in 13 individual items in the automation queue. Lets 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

So that's 1 + 2 + 5 + 5 = 13 items all up.

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!).

Why are lots of items in the queue bad?

The infrastructure handles lots of items in the queue. However, single rules that insert lots of items, are detrimental for Automation for Jira's performance. We've seen one customer's rule inserting over 100,000 items in the Cloud automation queue and all 8 processors for that customer were busy for hours processing that queue, delaying all their other rules.

To get around this to some extent, certain rule executions are prioritized (e.g. Manual rule triggers are executed first), but this approach can only go so far.

Throttle and disable

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:

Queued limit exceeded

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).

Prevention

Finally you've arrived at the spicy part! Luckily most rules don't execute for quite so many issues on every execution. There's a number of options to help reduce this problem:

  • Ensure you use JQL that limits 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 = Task if 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 executed checkbox. For many rules, it's perfectly fine to operate only on this small sub-set
  • 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.

If you're unsure about how to do this for your rule, please contact us in support!