Understand the difference between Automation limits and usage in Jira Cloud
プラットフォームの注記: Cloud のみ - This article only applies to Atlassian apps on the クラウド プラットフォーム上のアトラシアン製品にのみ適用されます。
要約
If your automation rule was throttled, stopped running, or shows a "monthly limit reached" error, use this article to identify which limit you hit and what to do next.
Jira Cloud automation enforces two independent limits:
Usage limit: a monthly cap on the total number of successful rule runs for your product. When you hit it, all rules for that product stop running until the start of the next month.
Service limit: a per-execution cap on how much processing a single rule can do (JQL result size, queued items, processing time). When a rule breaches a service limit, that rule is marked
THROTTLEDin the audit log and may be disabled.
The two limits behave differently and have different fixes. Identify which one you hit using the decision section below, then follow the matching "What to do next" steps.
ソリューション
"Which Limit Did I Hit?"
If you're not familiar with accessing the automation audit log, What is an automation audit log? and Audit the run logs of automation flows.
What you're seeing | limit |
THROTTLED status in the audit log | Service limit |
"...spent more than the allowed total time processing..." | Service limit (processing time) |
"...exceeded the allowed maximum number of work items to retrieve..." | Service limit (JQL result cap) |
"...exceeded the allowed maximum number of rule executions in the last hour" | Service limit (executions/hr) |
All rules for the product stopped at the same time | Usage limit |
Usage screen says "monthly limit reached" | Usage limit |
Email: "You've reached your monthly automation limit" | Usage limit |
Usage limit
How a run is counted:
A successful rule run (performs at least one action) counts as one. Multiple actions in the same run still count as one.
Runs that fire but perform no action (filtered out by a condition) do not count.
System rules created by Atlassian do not count.
Logging-only actions and variable creation do not count.
Each Cloud product has its own pool
Limits are no longer shared across products as of the November 2023 packaging change.
What happens + how to check
When hit: All rules for that product stop until the limit resets at the start of the next calendar month. Unused runs do not roll over.
How to check: Settings (cog) → System → Automation flows → Usage tab. Shows current usage, plan limit, and projected end-of-month usage. Requires Administer Jira global permission.
Usage limit: what to do next
Situation | 操作 |
Runaway rule (recursive trigger, accidental loop) | Disable the rule immediately, then contact Support to request a usage credit for accidental runs. |
Usage consistently near the limit | Optimize rules first. Scope rules to single projects, remove Related work items branches that fan out, and consolidate near-identical rules. |
Genuinely need more runs/month | Upgrade your plan. Each tier ships with a higher monthly limit (Free → Standard → Premium → Enterprise). Enterprise has unlimited runs. |
Just need to get through this month | Wait for the reset. Limits reset at 00:00 UTC on the 1st. Stopped rules resume automatically. |
Disabling a rule does not refund usage already counted in the current month.
Service limit
Common service limits
Per-execution caps, enforced platform-wide, cannot be raised via plan upgrade
limit | What it caps | When breached |
JQL result size | Items returned by a single JQL search inside a rule | Rule fails with THROTTLED |
Processing time/day | Cumulative time a single rule spends executing in 24h | Rule is throttled |
Rules per hour | Total rule executions in a one-hour window | New executions throttled |
Queued items | Items added to queue by a single execution | Rule is disabled |
Concurrent executions | Rules running in parallel across the site (8 in Cloud) | Rules wait their turn (delay, not failure) |
Service limit: what to do next
Situation | 操作 |
JQL returned too many items | Tighten JQL to <1,000 items. Use specific status, project, or updated > -1w filters. Split into multiple rules with non-overlapping JQL. |
Processing time exceeded | Reduce frequency (hourly instead of every 5 min). Remove unnecessary branches. For one-off bulk edits, use Jira's bulk change instead. Edit multiple issues at the same time |
Rules/hour exceeded | Look for rules that trigger each other in a chain. Add early if/else conditions to short-circuit. Consider scheduled rules over high-frequency event triggers. |
Queued items limit hit | Almost always caused by Related work items branches over large result sets. Replace with tighter JQL or batch in a separate scheduled rule. |
Rule was disabled by automation | Re-enable only after fixing the root cause. Re-enabling without changes will cause immediate re-throttle. |
Want to know before hitting a limit | Set up a Service limit breached trigger in a separate notification rule to alert via Slack or email. |
Proactive Monitoring
Monthly usage trend
Settings → System → Automation flows → Usage tab shows: current month-to-date runs vs plan cap, projected end-of-month usage, top rules by usage, and top rules by error rate. Requires Administer Jira global permission.
Service-limit risk & alerts
Top rules by run time in the same screen surfaces rules close to processing-time limits. Review the top three regularly. Create a dedicated notification rule using the Service limit breached trigger to post to Slack, email a project admin, or create a Jira issue when any rule approaches a limit.
Quarterly audit
Open the global automation audit log (Settings → System → Automation flows → Audit log) and filter to THROTTLED for the last 60 days. A pattern of throttling on a single rule is a leading indicator it needs to be split or rescoped.
Common Throttling Patterns
High-frequency scheduled trigger
Symptoms: Rule runs every 5 minutes, scans hundreds of issues per run, hits processing-time limits within hours.
Increase schedule interval to the longest acceptable (hourly is usually enough for non-SLA workflows).
Tighten JQL with updated > -1h so each run only handles items changed since the previous run.
Tick "Only include work items that have changed since the last time this rule executed."
Recursive triggers
Symptoms: Rule runs, action updates a field, field-update re-triggers the same rule, repeat. Hits rules-per-hour limit and burns monthly usage.
Add an early if/else condition checking whether the rule has already acted (e.g., a label automation-processed).
Scope triggers to a specific field change rather than "Issue updated".
Set Allow rule trigger to No so the rule's own actions don't re-fire other rules.
Related items fan-out
Symptoms: Rule queues thousands of items per execution, hits queued-items limit, gets disabled.
Replace Related work items branches with a single branch using specific JQL to match only needed items.
Rewrite conditional checks as a single branch with an if/else block on issue type; can reduce queued items by 10x or more.
Global rule duplication
Symptoms: A global rule and a per-project rule do the same thing; each event counts twice towards monthly usage.
Audit rule list for duplicates with the same trigger and action.
Prefer per-project rules (cheaper, easier to debug, billed per project on Premium).
If a cross-project rule is genuinely needed, scope it to specific projects rather than All projects.
Additional references:
この内容はお役に立ちましたか?