robotsnoindex
robotsnoindex

The following automation service limits have been applied to ensure the performance of your instance is maintained.

Summary

Limit

How might this limit breach?

Components per rule

65

A single rule contains more than 65 conditions, branches and actions.

New sub-tasks per action

100

A rule executes the creation of over 100 sub-tasks.

Issues searched

1000

A scheduled JQL search that isn't streamlined enough and returns more than 1000 issues.

Concurrent scheduled rule executions

1

A scheduled rule that takes longer than 5 minutes to execute, scheduled every 5 mins. Only single concurrent executions of this rule is allowed.

Items queued by rule

5000

For more information, see: Queued items service limit, below.

Items queued globally

50000

Similar to Items queued by rule, but applies to rules in progress across your Jira instance globally.

*Daily processing time

60 min per 12 hrs

A rule executes every 5 mins and each execution takes longer than 5 seconds. This could be the case, for example, if your rule talks to slow external systems.

*Hourly processing time

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

Loop detection

10

This controls how many times a rule can trigger itself (or other rules) in quick succession before the execution is stopped and marked as a LOOP.

*You can use the Service limit breached trigger to create an automation rule to send a notification when you are approaching the daily or hourly processing limit.

Breaching limits

The following errors in your audit log may indicate that you’re breaching service limits:

  • The audit item status is THROTTLED.

  • The audit item contains:

    • Automation for Jira has exceeded the allowed total processing time for this rule. Maximum allowed processing time over 12 hours is (in seconds):

    • 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 service limits, the audit log will provide further details about the error.



Using the information provided in the audit log, you can take several steps to ensure your rules fall below the acceptable limits. Some common precautions include:

  • Reducing the interval at which a scheduled rule executes. For example, only execute a rule every hour instead of every 5 minutes.

  • Restricting your JQL query to only search for the issues you care about. For example, check that the updated time of the issue is within a certain range (updated > -1w to include only last week's issues).

  • Splitting 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, using Jira's bulk change functionality.

Queued items service limit

Automation uses a rule processing queue to manage the execution of rules in your instance. To maintain performance, rule executions are queued and the number of items processed in parallel is limited.

The automation rule builder is powerful and can allow users to create complex rule structures that can quickly increase the number of queued items.

When a rule reaches its queued items limit, the details are recorded in the audit log and the rule is disabled to prevent future executions.

What types of rules can cause this?

Rules with many related issue branches, where each related issue branch matches a significant number of issues.

The following example results in approximately 13,000 queued items.

  • A Scheduled trigger that matches 100 issues

  • A Related issues branch that matches 50 issues

  • Another Related issues branch that matches 80 issues

Rules with many Related issue branches, to simulate if conditions, can also cause large numbers of queued items. The following examples results in 3,500 items or more, depending on the number of branches.

  • Trigger: Issue updated

  • Related issues branch with JQL: type = Bug that matches 1000 issues

  • Related issues branch with JQL: type = Task that matches 500 issues

  • Related issues branch with JQL: type = Feature that matches 2000 issues

Prevention

It’s recommended to reduce the overall number of issues a rule fetches, either via the trigger or the Related issues branch.

Consider the following guidelines to help reduce the risk of hitting your queued items service limit:

  • 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. Don't just search for issues that match type = Task if you only care about issues currently In Progress. A better alternative in this case would be: type = Task and status = "In Progress".

    • Use the Only include issues that have changed since the last time this rule executed option. For many rules, it's perfectly fine to operate only on this small sub-set

  • Don't create Related issue branches for conditional checks. In the above example, the If/else block condition could be used to match based on the issue type.