Automation service limits
During maintenance windows, some automation flows may fail to successfully execute as intended.
The following automation service limits have been applied to ensure the performance of your instance is maintained.
Summary | Limit | How might this limit breach? |
|---|---|---|
Steps per flow | 65 | A single flow contains more than 65 conditions, branches, and actions. |
Steps per advanced flow | 500 | An advanced flow contains more than 500 conditions, branches, and actions. |
Steps per flow group | 65 | A flow group contains more than 65 conditions, branches, and actions. |
Number of flow labels per cloud site | 600 | The total number of flow labels for a cloud site exceeds 600. |
New subtasks per action | 50 | A flow executes the creation of over 50 subtasks. |
Work items searched | 999 | A scheduled JQL search that isn't streamlined enough and returns more than 999 work items. |
Scheduled flows that can run at the same time | 1 | A scheduled flow that takes longer than 5 minutes to execute, scheduled every 5 mins. Only single concurrent executions of this flow is allowed. |
Associated items for a flow | 5,000 | Defines how many items a single flow execution can fetch. For example, a Scheduled trigger fetching 100 work items, followed by a related branch fetching 10 subtasks per work item, would add 100 * 10 = 1,000 associated items to this limit. When a flow reaches this limit, it’ll be disabled to prevent future runs. |
Items queued globally | 50000 | Similar to Items queued by flow, but applies to flows in progress across your Jira instance globally. |
*Daily processing time | 60 min per 12 hrs | This could be the case, for example, if your flow talks to slow external systems. |
Loop detection | 10 | This controls how many times a flow can trigger itself (or other flows) in quick succession before the execution is stopped and marked as a LOOP. |
100 emails in a 24-hour period. This limit only applies to the Free plan for Jira Cloud and Trial licenses. |
| |
Lookup work items action | 100 work items | When entering a JQL query for the Lookup work items action, only the first 100 work items will be used. |
Number of items a branch can retrieve per flow run. |
| For example, if a flow branch contains a CQL query that returns more than 150 items, the flow will only perform actions on the first 150 items. |
Number of flows that can run at the same time |
If you have multiple apps on different plans, only the highest limit will count. | For example, if you have Jira Service Management Enterprise and Jira Cloud Free, your site will be able to run 30 flows at the same time. |
Limits for some Confluence AI actions | 1,000 uses of Generate AI action items and Summarize with AI per 12 hours | This applies only to the following Confluence actions:
|
Fields limit for work items processed by automation flows | 2,000 fields | This applies to the following actions:
|
Limits for Rovo Agent usage in Automations | 500 requests per minute (soft limit) | This applies to the "Use Rovo Agent" action and is counted across all executed flows. This is a soft limit and exceeding exceeding this limit will not normally result in request limiting. |
*You can use the Service limit breached trigger to create an automation flow 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 flow. Maximum allowed processing time over 12 hours is (in seconds):A JQL search in this automation flow has exceeded the allowed maximum number of work items to retrieve per search. Only the first work items up to the following limit where processed:
When a flow 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 flows fall below the acceptable limits. Some common precautions include:
Reducing the interval at which a scheduled flow executes. For example, only execute a flow every hour instead of every 5 minutes.
Restricting your JQL query to only search for the work items you care about. For example, check that the updated time of the work item is within a certain range (updated > -1w to include only last week's work items).
Splitting your automation flow across several flows if you need more steps per rule.
For large, one-off operations that need to edit several thousands of work items, using Jira's bulk change functionality.
Queued items service limit
Automation uses a flow processing queue to manage the execution of flows in your instance. To maintain performance, flow executions are queued and the number of items processed in parallel is limited.
The automation flow builder is powerful and can allow users to create complex flow structures that can quickly increase the number of queued items.
When this limit is reached across all flows in your app, your automation flows will no longer run.
What types of flows can cause this?
Flows with many related work item branches, where each related work item branch matches a significant number of work items.
The following example results in approximately 13,000 queued items.
A Scheduled trigger that matches 100 work items
A Related work items branch that matches 50 work items
Another Related work items branch that matches 80 work items
Flows with many Related work item 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: Work item updated
Related work items branch with JQL: type = Bug that matches 1000 work items
Related work items branch with JQL: type = Task that matches 500 work items
Related work items branch with JQL: type = Feature that matches 2000 work items
Prevention
It’s recommended to reduce the overall number of work items a flow fetches, either via the trigger or the Related work items 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 work items. This can be achieved in a number of ways:
Ensure your JQL search is as specific as possible. Don't just search for work items that match
type = Taskif you only care about work items currently in progress. A better alternative in this case would be:type = Taskandstatus = "In Progress".Use the Only include work items that have changed since the last time this flow executed option. For many flows, it's perfectly fine to operate only on this small subset
Don't create Related work item branches for conditional checks. In the above example, the If/else block condition could be used to match based on the work item type.
Was this helpful?