Automation fails with "This step has exceeded rate limits" when generating a large number of subtask

Question

Hi Community,

I'm currently testing Jira Automation in a Jira Cloud Premium Sandbox environment and would appreciate any insights regarding automation rate limits.

■Environment

- Jira Cloud Premium
- Sandbox environment
- Automation rules for automatic subtask creation

■Configuration

There are four different work item types, and each work item type has its own Automation rule.

Each rule is triggered when a parent issue transitions to a specific status and then automatically creates a subtask.

■Test Scenario

I created approximately 400 parent issues and performed the status transition.

For each parent issue, the corresponding Automation rule creates a subtask based on the applicable work item type.

■Observed Behavior

Subtask creation works correctly up to around 250 parent issues.

After that point, the Automation audit log starts showing the following error:

"This step has exceeded rate limits."

Once this occurs, subsequent subtasks are no longer created.

Initially, the audit log displayed the rate limit error above. However, subsequent audit log entries only show "Multiple errors" without providing detailed information about the underlying component failures.

The issue is not limited to a single Automation rule. The same behavior occurs across multiple work item-type Automation rules.

■Additional Information

- Jira Cloud Premium subscription

- Monthly Automation execution limit: 200,000

- Current usage is less than 1%

- The audit log indicates a rate limit error rather than a monthly execution limit issue

- Testing is being performed in a Sandbox environment

- The first rate limit errors started appearing around the 248th issue

■Questions

* Does Jira Cloud Automation have any rate limits related to large numbers of executions within a short period of time?

* Are there any Sandbox-specific limitations or differences compared to Production?

* Has anyone experienced similar behavior when bulk-generating large numbers of issues or subtasks using Automation?

* Are there recommended workarounds, such as batch processing, delays, scheduled execution, or any other best practices?

* Is it expected behavior that, after the initial rate limit error, the audit log only shows "Multiple errors" without more detailed information?

Any insights or experiences would be greatly appreciated.

Thank you.

Gor Greyan · Accepted Answer

Hi @nagata shumpei

What you're hitting appears to be an Automation service limit, not your Premium monthly execution allowance. Those are separate limits, so having less than 1% monthly usage doesn't prevent a rule from being throttled.

Creating ~400 parent work items and immediately triggering four different rules to create subtasks can generate a large burst of Automation executions. The fact that failures start around the same point across multiple rules also suggests site-level queue/concurrency pressure rather than a problem with one particular rule.

I would avoid generating all 400 at once. Process them in smaller batches or use scheduled rules/JQL to spread the subtask creation over time, ideally outside peak hours. Atlassian specifically recommends this approach for large bulk Automation workloads.

Also check Global Automation → Performance insights around the time of the test; this can show whether the Automation queue was saturated.

Atlassian's service limits documentation is here.

https://support.atlassian.com/cloud-automation/docs/automation-service-limits

Regards,
Gor

Arkadiusz Wroblewski · Accepted Answer

Hello @nagata shumpei

Also this article can be significant for you Rate limiting

Gabriela - LeanZero · Accepted Answer

Adding the numbers to Gor's point, because the figure is what tells you whether 400 at once was ever going to work. The service limits table gives "Number of flows that can run at the same time" as Free 5, Standard 10, Premium 20, Enterprise 30, alongside a separate cap on total rule executions in a one-hour window.

You can't buy your way out of that one. Service limits are "Per-execution caps, enforced platform-wide, cannot be raised via plan upgrade", so the upgrade that lifts your monthly allowance leaves this one exactly where it is.

Be ready for conflicting numbers. A second Atlassian page describes that same limit as "Rules running in parallel across the site (8 in Cloud)", a flat 8 rather than the tiered figures above. Same limit, two published answers.

On your sandbox question, which I don't think anyone has picked up: neither limits page mentions sandbox anywhere at all, so I can't say there is a difference and I can't say there isn't.

For the bulk creation itself the docs point away from automation entirely: "For one-off bulk edits, use Jira's bulk change instead."

Trudy P Claspill · Accepted Answer

I have encountered a similar problem, not with creating issues but with using the Lookup Objects action for assets.

I had a branch that would iterate over a list of IDs that corresponded to 100-500 objects. Within the branch for each ID there would be a Lookup Object action to look up that object, and then an additional 8 Lookup Object actions would execute each retrieving just one other object (to use to set an object attribute in the original object). The last step in the branch was an API call to update the original object from the branch action.

I would often get the rate limit exceeded message.

Researching with multiple AI tools and really digging into the details, the conclusion that was reached had multiple factors impacting he results.

1. The iterations of a branch are executing in parallel, not just sequentially. The branch was not doing 8 lookups, then 8 more, then 8 more. It could be executing 8 lookups time N objects all at once.

2. Behind the scenes, API calls were being used to execute the Lookup Object actions.

3. Branch operations happen very quickly.

With all these factor operating at once, the rate limit actually being exceeded was the API Burst Rate Limit - too many calls to the API behind Lookup Objects were happening in to short of a time period.

In my case I had to find a way to break my rule into batches so that 100 or less items would be processed by the branch.