Jira Automation Pricing Is Changing: From Flow Runs to Steps

Jira automation pricing no longer counts flow runs. It counts steps: every trigger, condition, action, branch and loop that runs inside a flow. Automation is still included in every Jira plan, with a monthly step allowance pooled across your organization: 400 steps per user on Standard, 750 on Premium and 1,000 on Enterprise. Steps beyond the allowance cost $0.50 per 1,000, billed from December 3, 2026, and runs that match nothing now count too.

Key takeaways

• One automation run now costs several steps. A trigger plus one action is 2 steps; a rule that branches over linked work items can cost dozens.
• Runs that stop at a condition or match nothing are now charged. Under the old model, they were free.
• Jira Service Management Premium agents bring 6,500 steps each, nearly nine times a Jira Premium user, and all allowances share one pool.
• Enterprise plans are no longer unlimited.
• The overage bill is usually small. The bigger risk is automation stopping: if extra usage is off and the pool runs out, triggering events are lost, not queued.

Why trust this guide: Empyra is an Atlassian Platinum Solution Partner with 15+ years of Atlassian experience, 80+ certified consultants and 1,000+ customers, including Rakuten, Victoria's Secret, Houston Community College, Sally Beauty and UC Office of the President. The rule rewrites in this guide start from automation examples we published ourselves, recalculated under the new step model.

Flow runs vs steps: what actually changed

Atlassian now calls automation rules "flows." Under the old model, each successful flow run counted once, however many actions it performed. Under the new model, every part of the flow that runs is counted. The step meter is already live, so your real usage is visible in Atlassian Administration today; only the billing for steps beyond your allowance waits until December 3.

Source: Atlassian, How is your automation usage calculated, as of 12th of Oct 2026.

In practice: a rule with a trigger, two conditions and three actions used to cost 1 run. Now it costs 6 steps when it runs end to end, and 2 steps every time it fires and stops at the first condition. That second number is the one most teams underestimate. Because your limit now depends on your seat mix rather than a flat run count, comparing old and new allowances is really a licensing question, and it's one our Atlassian license management team answers during renewal planning.

Automation step allowance by plan

Every plan includes a monthly step allowance. Allowances from every product add up into one shared pool for your organization and refresh monthly, with no rollover.

Two things stand out in this table.

• Service desk seats carry most of the pool. Because the pool is shared, an organization with a service desk is often funding its software teams' automation with its agents' allowance. Reduce JSM agent seats and your whole organization's automation budget shrinks, not just the service desk's. Seat counts and step allowances are now one licensing decision, so plan them together.
• Enterprise is now an allowance, not unlimited. Enterprise customers who built heavy automation on the assumption it was free at any volume need to measure usage before they plan anything else.

Example: an organization with 25 JSM Premium agents and 150 Jira Standard users gets (25 × 6,500) + (150 × 400) = 222,500 steps a month, shared by every flow in every app.

What counts as an automation step, and what doesn't

What counts

Each time one of these runs inside a flow, it's one step:

• Triggers: the event that starts the flow
• Conditions: the checks that decide whether the flow continues
• Actions: the work the flow does
• Branches: if/else paths
• Loops: repeated actions, counted once per iteration

A step is charged when it ends in any of these statuses: SUCCESS, NO_ACTIONS_PERFORMED, SOME_ERRORS, ABORTED or NO_MATCH. That last one matters most: even when a trigger finds nothing to act on, the trigger itself costs one step.

What doesn't count

• System components Atlassian runs on your behalf
• Throttled runs where no step executes, and errors on Atlassian's side
• Rovo and agent components. "Use Rovo", "Use agent" and "Use Jira Coding agent" are billed in Rovo credits and don't consume automation steps. The rest of the flow around them still does. For a quick estimate of the AI side, use our Rovo credits calculator.

What Jira automation costs beyond your allowance

Automation itself has no separate price: it's included in your subscription. You only pay when your organization uses more steps in a month than its pooled allowance, and only if extra usage is turned on.

Atlassian's formula:

(Steps used − included allowance) ÷ 1,000 × $0.50 = extra usage charge

You may see other per-step rates quoted online. Atlassian's own documentation lists $0.50 per 1,000 steps, so check that page rather than a secondary source. If you want fixed spend instead of a monthly variable charge, Atlassian also sells prepaid automation step packs. Whether packs, a limit or a plan change is cheapest depends on your seat mix, and that comparison is part of every Atlassian license management review we run.

If extra usage is on

Flows keep running. Organization and billing admins get alerts at 80% and 100% of the allowance, and extra steps appear on the next invoice. Admins can set a monthly limit to cap spend.

If extra usage is off, or your limit is reached

• New flow runs stop until the allowance resets or you add a usage pack. Flows already mid-run finish.
• Triggering events are not queued. A ticket created while flows are paused won't be routed later; it simply misses the automation.
• Flows with manual triggers pause too.
• Flows stay configured and resume automatically after the reset. The audit log shows which flows would have run during the pause.

Atlassian's documentation isn't fully consistent on whether extra usage is on by default, so check the setting in Atlassian Administration. For most service desks, a silent stop costs far more than the overage: missed assignments, missed SLA escalations and unrouted tickets. That's why many teams keep extra usage on with a sensible limit rather than switching it off.

Source: Atlassian Automation licensing FAQ.

Will Jira automation cost you more? Convert your runs to steps

The fastest way to see whether the new model affects you is to translate your step allowance back into runs. Divide the allowance by the average number of steps your flows use per run.

Calculated from Atlassian's published allowances.

Compare that with the old Jira Premium allowance of 1,000 runs per user. If your flows average 4 steps per run, a Premium user's 750 steps buy about 187 runs, less than a fifth of the old allowance. And the comparison flatters the new model, because the old one didn't count runs that matched nothing.

How to find your own average

• In Atlassian Administration, go to Insights → Platform usage and note the automation steps used so far this month.
• In Jira automation, use the audit log to count flow executions over the same period, including runs marked "No actions performed".
• Divide steps by executions. That's your average steps per run, and the row of the table that applies to you.

Who should check now, and who is probably fine

Check your usage this week if you are:

• On an Enterprise plan that used to have unlimited automation
• A Jira-only organization with no JSM or Teamwork Collection seats adding to the pool
• Running scheduled flows every 15 to 60 minutes
• Using global or multi-space flows triggered on every work item created or updated
• Planning a migration, data import or large bulk edit

You're probably fine if your organization has a large share of JSM or Teamwork Collection seats and your flows are mostly event-based with few conditions. Confirm it in Platform usage anyway; it takes two minutes.

The 4 rule patterns that burn Jira automation steps

Most step usage comes from a handful of rule shapes, not from the number of rules you have.

1. Broad triggers that rarely match

A rule triggered on every new work item, with a condition that only lets 5% of them through, pays for the other 95% too. Each non-match costs at least 2 steps: the trigger and the first condition. Narrowing a flow's scope to the spaces that actually need it is often the single biggest saving.

2. Branches over many work items

A branch that loops over linked items or subtasks runs its conditions and actions once per item. A rule that looks like five components on screen can cost 40 or 50 steps on a problem ticket with 20 linked incidents.

3. Scheduled rules that poll

A flow scheduled every 15 minutes fires 2,880 times in a 30-day month, and every firing costs at least one step, even when it finds nothing. If it then checks conditions on each work item it finds, the count multiplies.

4. Bulk edits

Bulk-editing hundreds of work items fires every "work item updated" or "field value changed" rule once per item. One Atlassian Community member reported a bulk update consuming around 80% of their monthly automation quota within a few hours. Before a large bulk change or data import, check which flows it will trigger, and pause the ones you don't need during the change.

Before and after: 3 ITSM rules rewritten for steps

These examples start from the rules in our earlier guide to Jira automation rules for ITSM. They were built for the flow-run model, where extra conditions were free. Under steps, the same rules cost noticeably more, so we rebuilt them.

How we counted: each trigger, condition, action and branch component that runs is one step, and each loop iteration is counted separately, following Atlassian's definition. Ticket volumes are illustrative assumptions, not client data. At the time of writing, Atlassian doesn't show step counts per flow, so after you change a flow, confirm the saving by comparing your total usage in Platform usage before and after.

Rule 1: Smart incident assignment

Before (as published): trigger on work item created; three separate conditions (type is Incident, summary mentions network or VPN keywords, priority is High or Critical); four actions (assign, comment, add labels, notify the team).

After:

• Scope the flow to the service space only, so work items created in other spaces never trigger it.
• Replace the three conditions with one JQL condition: issuetype = Incident AND priority in (High, Critical) AND summary ~ "network OR connectivity OR internet OR VPN".
• Set the assignee and labels in one "Edit work item" action instead of two.
• Keep the comment and the notification.

That's a 22% saving on one rule. The bigger lesson: under the old model, this rule cost 100 runs a month, because only matching tickets counted. Under steps, the 1,900 tickets it ignores cost more than the 100 it acts on.

Rule 2: SLA escalation (the expensive one)

Before (as published): a scheduled trigger every 15 minutes, checking high-priority incidents for 70% of their resolution SLA used, then adding a manager as watcher, notifying, and updating labels and priority.

Scheduled every 15 minutes, this flow fires 2,880 times a month before it does anything useful. If about 10 high-priority incidents are open at any time and the flow checks two conditions on each, that's about 21 steps per firing, or around 60,000 steps a month before a single escalation action runs. That's the entire monthly allowance of 80 Jira Premium users, or about nine JSM Premium agents.

After: replace polling with Jira Service Management's SLA threshold breached trigger, which runs only when a ticket's SLA is about to breach or has breached.

• Trigger: SLA threshold breached; SLA = Time to resolution; "will breach in the next" set to 30% of your SLA target. For a 4-hour SLA, 70% used means 1 hour 12 minutes left.
• Condition: one JQL condition that also covers the manager check, for example issuetype = Incident AND priority in (High, Critical) AND assignee not in membersOf("managers"). Use the name of your own manager group.
• Actions: add the manager as watcher, send the notification, and update labels and priority in one edit.

Two cautions. The SLA trigger reacts to tickets as they cross the threshold, so tickets already past it when you switch won't fire it. And if you also want the original rule's "create a manager review subtask below 30%" step, build it as a second SLA threshold flow rather than another scheduled one.

Rule 3: Closing linked incidents when a problem is resolved

Before: trigger on any transition to Done; branch over all linked work items; for each one, a condition checking it isn't already Done, then a transition and a comment.

After:

• Add a JQL condition right after the trigger, so the flow continues only for Problem tickets.
• Filter inside the branch with JQL, so already-closed incidents are never looped over and need no per-item condition. For example: issue in linkedIssues(PROBLEM-KEY, “causes”) AND statusCategory != Done. In the rule itself, PROBLEM-KEY is filled in automatically with the issue.key smart value. 

The "before" version also fired on every work item moved to Done in the space, costing at least one step each time. The "after" version still pays for its trigger on those, but stops at the first condition. Atlassian hasn't documented whether a branch component counts once per run or once per item, so treat branch figures as estimates.

Want us to audit your flows? Our Jira Service Management consulting team reviews your heaviest flows, rewrites them for steps and checks the change in Atlassian Administration. Book a Jira automation audit

A 30-minute Jira automation step audit

Work through this list before extra usage billing starts:

• Check your usage. In Atlassian Administration, go to Insights → Platform usage and compare automation steps used so far with your total allowance.
• Check extra usage. Confirm whether it's on, set a monthly limit, and make sure the right admins receive the 80% and 100% alerts.
• List your scheduled flows. Anything running every 15 or 30 minutes is a candidate for an event-based trigger, such as SLA threshold breached, or a longer interval.
• Find your broadest triggers. Global or multi-space flows triggered on "work item created" or "updated" usually pay for many non-matches. Narrow their scope.
• Merge conditions. Several conditions in a row can usually become one JQL condition.
• Plan bulk changes. Before imports and bulk edits, pause flows that don't need to run on those items.
• Factor seats into the pool. Any license reduction, especially JSM agents, lowers your automation allowance. Run Atlassian license optimization and your automation review together.

How Empyra helps you control Jira automation costs

When we recalculated the rules from our own earlier ITSM automation guide, a single scheduled SLA flow turned out to cost more steps than all the other example rules combined. That pattern, timers doing work an event trigger could do, is the first thing we look for in any automation review.

As an Atlassian Platinum Solution Partner, Empyra covers both sides of the change:

• Flow audits and rewrites. Our consulting team reviews your heaviest flows and rebuilds them to do the same job in fewer steps, including Jira workflow management and service desk automation through our ITSM consulting practice.
• Allowance and limit planning. Our license management team models your pooled step allowance against real usage, sets limits and weighs step packs against a plan or collection change.
• Ongoing monitoring. With Atlassian managed services, we track usage monthly so new flows don't drift back into step-heavy patterns.

Next step: fix the flows that cost the most

The move from flow runs to steps doesn't change what your automation does, only how it's counted. The flows that cost the most are rarely the most important ones: scheduled polling, broad triggers and branches that loop over everything. Fix those, set a sensible limit, and the new model is easy to live with.

You don't have to work through every flow on your own. Our Atlassian consulting services team can find the flows using the most steps, rebuild them to do the same job for less, and confirm the saving in your usage data. Book a Jira automation cost review to get started.