Blog ·
Jira Cloud automation limits: every service limit, explained
Jira Cloud automation limits come in two kinds, and it helps to know which one you are looking at. The first is the monthly step allowance, which is a usage meter tied to your plan and covered in Jira Automation pricing. The second is the set of service limits Atlassian applies to every flow regardless of plan: at most 65 steps in a flow, 999 work items from a scheduled JQL search, one concurrent run of any scheduled flow, 5,000 associated items per execution, and 60 minutes of processing time per 12 hours. This page lists those service limits as Atlassian publishes them as of September 2026, says what a breach looks like in the audit log, and picks out the ones a scheduled flow is most likely to hit.
The two kinds of limit #
A usage limit is about money. When your organisation spends its monthly step allowance, flows either keep running and the extra steps are billed, or they stop until the allowance resets, depending on a setting.
A service limit is about the health of the shared platform. It applies on every plan, it is not something you can buy more of, and it usually stops one flow rather than all of them. When people search for automation limits they tend to mean this second kind, because it is the one that turns a working rule into a THROTTLED line in the audit log without warning.
Every Jira Cloud automation service limit #
These figures are from Atlassian's automation service limits page, read in September 2026.
| Limit | Value | What breaches it |
|---|---|---|
| Steps per flow | 65 | A flow with more than 65 conditions, branches and actions |
| Steps per advanced flow | 500 | An advanced flow with more than 500 steps |
| Steps per flow group | 65 | A flow group with more than 65 steps |
| Flow labels per site | 600 | More than 600 labels across the cloud site |
| New subtasks per action | 50 | One action creating more than 50 subtasks |
| Work items searched | 999 | A scheduled JQL search returning more than 999 work items |
| Concurrent runs of one scheduled flow | 1 | A flow that takes longer than its own interval |
| Associated items per execution | 5,000 | Trigger results multiplied by branch results |
| Items queued globally | 50,000 | All flows in progress across the site |
| Processing time | 60 min per 12 hrs | Flows that wait on slow external systems |
| Loop detection | 10 | A flow triggering itself or others in quick succession |
| Send email action | 100 per 24 hrs | Free plan and trial licences only |
| Lookup work items action | 100 work items | Only the first 100 results are used |
| Fields per created or cloned work item | 2,000 | Create or clone actions on very wide work items |
Two more depend on your plan. The number of flows that can run at the same time is 5 on Free, 10 on Standard, 20 on Premium and 30 on Enterprise, and if you have several Atlassian apps on different plans, only the highest limit counts. Confluence branches that iterate pages, tasks or CQL results stop at 150 items each.
What a breach looks like #
Atlassian names the signs in the audit log. The status of the audit item is THROTTLED, or the item carries one of these messages:
Automation for Jira has exceeded the allowed total processing time for this flow.
A JQL search in this automation flow has exceeded the allowed maximum number of work items to retrieve per search.
The second one is the quiet one. The flow still runs, on the first 999 work items only, and the rest are simply left out. Nothing on the work items themselves says a flow skipped them.
The associated items limit is harsher. Atlassian's page states that when a flow reaches it, "it'll be disabled to prevent future runs". A scheduled flow that fetched 100 work items and then branched to 10 subtasks each has already used 1,000 of its 5,000.
Atlassian also offers a Service limit breached trigger, which you can use to build a flow that notifies someone when you approach the daily or hourly processing limit. If your team relies on automation for anything that must happen on time, that notification is worth setting up before you need it.
The limits a scheduled flow hits first #
Most recurring work in Jira is a scheduled flow: every Monday, create the maintenance ticket; on the first of the month, create the report ticket; each quarter, create the access review. For flows shaped like that, four limits matter far more than the rest.
One concurrent run #
A scheduled flow can only have one execution in progress. Atlassian's example is a flow scheduled every 5 minutes that takes longer than 5 minutes to run. For a weekly create-one-ticket flow this never fires. It starts to matter when a scheduled flow also sweeps a JQL result, because the sweep is what makes it slow.
999 work items per scheduled search #
A scheduled trigger with JQL runs its actions on the work items the query returns. A query that grows over time, for example every open task in a project, can cross 999 without anyone noticing, and from then on the flow works on a subset. Atlassian's advice is to narrow the query, for instance updated > -1w, or to use the option that only includes work items changed since the last execution.
50 subtasks per action #
If your recurring ticket carries a checklist as subtasks, one create action can add at most 50. Few checklists are that long, but a quarterly audit template that grew by accretion can get there.
65 steps per flow #
Teams often build one large scheduled flow with an if/else branch per team or per project to avoid maintaining many small ones. That design meets the 65-step ceiling, and Atlassian's own remedy is to split the flow into several. Splitting also spends more of the monthly allowance, since each flow's trigger counts as a step every time it fires.
How to stay under the limits #
Atlassian lists the common precautions on the same page, and they are sound:
- Run less often. A flow that runs every hour instead of every 5 minutes runs a twelfth as often, and spends its processing time accordingly.
- Tighten the JQL. Search for the work items you actually care about, such as
type = Task and status = "In Progress", rather than every task. - Use if/else instead of related-item branches for conditions. A related work items branch fetches items, and fetched items count toward the queued and associated limits.
- Split long flows. Several short flows stay under 65 steps each.
- Use bulk change for one-off edits. Editing thousands of work items once is a job for Jira's bulk change, not a flow.
For recurring creation specifically, the cheapest precaution is structural: keep the flow that creates the recurring ticket separate from any flow that sweeps or edits existing work. The creating flow then stays small, fast and nowhere near a limit, and a throttled sweep cannot take it down with it. The Jira automation examples article walks through six common rules and where each one breaks.
Who should stay with Jira Automation #
Most teams, for most work. The service limits are generous for flows that do one thing on a schedule, and Automation is already included in your plan.
- Your scheduled flows create a handful of tickets and nothing else. None of the limits above will trouble them.
- Your flows do more than create. Transitions, JQL sweeps, notifications and cross-product actions are what Automation is built for.
- You want one rule across many projects. Automation handles that in one place.
If you are weighing Automation against a scripting app for the heavier jobs, Automation for Jira vs ScriptRunner compares the two.
When recurring tickets belong somewhere else #
There is one situation where the limits argue for moving the recurring half of the work out of Automation. That is when the tickets that must appear on time share a site with busy flows that are close to their limits. Queued items and processing time are counted across the instance, and when the queued items limit is reached, Atlassian's page states, "your automation flows will no longer run". The quiet Monday ticket stops along with the noisy sweep.
Recurring Work Items for Jira is built for that split. It consumes no Jira Automation quota, because it has its own scheduler and never creates or runs an Automation rule. A rule is a schedule plus an issue template, written once in one Jira project, with daily, weekly, monthly and quarterly options, working-day and holiday handling, dynamic titles and subtask checklists. Every occurrence, whether created, skipped or failed, is written to the rule's history with the reason, so a missed cycle is visible on the rule itself instead of in an audit log nobody reads. It is free for up to 10 users, then from $82.50 a year for 11 to 15 users.
It is scoped to one project at a time and has no site-wide rules, so a team that wants one rule spanning thirty projects is better served by Automation.
How to move a recurring flow over #
- List the scheduled flows whose only job is to create a work item on a date. Leave everything that edits, transitions or sweeps where it is.
- For each one, note the schedule, the summary, the fields it sets and any subtasks.
- Install the app, turn it on for the project, and write the rule. The tokens page covers dates in titles, such as the month a report covers.
- Let one cycle run in both places, check the new ticket, then disable the Automation flow.
The flows you keep in Automation are then only the ones that need it, and each is further from the limits that matter.