automation limit

Ivan Andrieiev_oq43e6

Perhaps I can find some advice here. Jira currently has a limit of 1,700 automations for the Standard plan. We’ve calculated that there’s a strong possibility we’ll exceed this limit, yet we don’t need the Premium plan. Are there any ways to increase this limit while staying on the Standard plan?

Gabriela - LeanZero

Quick reframe before you start pruning: the 1,700 isn't a cap on how many automation rules you can build — it's how many times your rules can successfully run in a month on Standard. You can have as many rules as you want; what you're actually rationing is executions.

Two things stretch that number a lot further than it looks. First, a run only counts when the rule performs at least one action — if it triggers but bails out at a condition before doing anything, it's free. So the biggest lever by far is pushing your conditions as early in the rule as possible, so rules exit before they act instead of after. A scheduled rule that wakes up, checks, finds nothing to do and stops costs you nothing. Second, the pool is per product, not per site: Jira Software has its own 1,700, but Jira Service Management gets 5,000 and Jira Product Discovery its own bucket, all counted separately. So automations that genuinely belong to a JSM or JPD project draw from that product's allowance rather than your Software 1,700.

One piece of old advice to ignore while you're at it: single-project rules used to be exempt from the count, and you'll still find people saying "just scope everything to one project." Atlassian removed that exemption back in late 2023 — every run counts now regardless of scope, so that trick won't buy you anything anymore.

On the actual question: there's no way to just raise the 1,700 on Standard. Premium is the only thing that changes the number itself, and it swaps to 1,000 runs per user rather than a flat cap. But most teams I've seen don't need the upgrade — they need to find the three or four rules doing most of the damage. Open your global automation and check the Usage view; it breaks consumption down per rule, and it's nearly always a couple of scheduled sweeps or rules that keep re-triggering each other. From there the usual wins are swapping timer-based schedules for event triggers, collapsing chains into one rule with branches, and moving genuinely high-volume deterministic work off automation entirely — ScriptRunner, a small Forge app, or your own script against the REST API via a webhook won't touch your automation quota at all.

Worth sorting before you're up against it, because when you do hit the cap every rule for that product stops running until the 1st of the next month (you'll get warning banners as you get close). If you can share what your heaviest few rules are actually doing, happy to point at where to cut.