Atlassian per-step billing · 3 December 2026
On 3 December 2026 Atlassian starts charging for Automation by the step. Drop in your rules export and see which rules spend the most steps, what is driving it, and what it would cost you a month.
automation-rules-*.json
No file needed. A complete worked analysis of a fictional 250-seat estate, in one click.
Jira: Settings → System → Automation → ⋯ → Export
Confluence: Space Settings → Automation → ⋯ → Export
The file downloads as automation-rules-*.json. You need Jira or Confluence admin rights to reach the Automation screen.
What Atlassian is charging for
Atlassian counts a step every time a rule component runs: the trigger that starts it, every condition it evaluates, every branch it walks, every action it takes, and every iteration of a loop. A rule that looks like three boxes in the editor can be a dozen steps by the time it finishes.
That is why two rules that look alike can bill very differently. A branch that fans out over fifty issues runs everything inside it fifty times, and every one of those counts.
A run counts when it reaches an outcome — Success, No actions performed, Some errors, Aborted, or No match. Runs that Atlassian throttles, and failures on Atlassian's own side, are not billed. Rovo agent steps are billed separately, as Rovo credits rather than automation steps.
No match and No actions performed are the two that surprise people. A rule that fires on every issue update and then immediately fails its condition does nothing all day and still spends its trigger and its conditions every single time.
Every Atlassian plan comes with a monthly step allowance. On paid plans it is counted per user and pooled across the whole organisation rather than per project, so a 200-seat Jira Standard site shares 80,000 steps a month.
| Plan | Jira | Confluence |
|---|---|---|
| Free | 150 per subscription | 50 per subscription |
| Standard | 400 per user | 100 per user |
| Premium | 750 per user | 250 per user |
| Enterprise | 1,000 per user | 500 per user |
Steps per month. Free plans get a flat figure for the whole subscription; paid plans scale with licensed seats.
Today, going past your allowance carries no per-step charge. From 3 December 2026, Atlassian bills usage above the included allowance at $0.50 per 1,000 steps. Nothing about your rules changes — the same automations you run now simply start carrying a line on the invoice once they pass the pooled limit.
The rules that dominate a step bill are rarely the ones anyone remembers writing. Usually it is a branch with no filter on it, a rule triggering on every issue update that fails its condition nine times in ten, or two rules quietly triggering each other. Each one is a small edit. Finding them after the first invoice is the same small edit, made under pressure, with a number attached to it.
Drop your rules export above and this page will rank every rule by steps per run, name the patterns driving them, and put a monthly figure on it — in your browser, without the file leaving the tab.
Questions
Yes. Confluence Automation exports in the same format and is parsed the same way, and the calculator has a separate Confluence plan tier and seat count because the two allowances are pooled separately. If you export from both, run them one at a time — the page analyses one export per pass.
Every iteration counts as a step, which is what makes loops and branches the most expensive structures in a rule. A branch over fifty issues runs its contents fifty times. Because the number of issues a branch will match is not knowable from the rule definition alone, this page does not invent a figure for it — it counts the branch itself and flags the rule as uncapped, so you can apply your own multiplier.
Jira Service Management rules export in the same format and are analysed like any other Jira rule. Rovo agent steps are billed by Atlassian as Rovo credits rather than automation steps, so they are outside what this page models. If your export contains rule types this page does not recognise, it counts their structure but will not flag patterns it has no rules for.
The steps-per-run figure is read directly from each rule's own structure, so it is exact for a run that completes every component. The monthly cost is only as good as the run counts it is multiplied by. Import your Automation audit log and those counts come off your real history; without it, scheduled rules are calculated from their own recurrence and the rest are yours to estimate. Treat the result as a ranked shortlist of where your steps are going, not as an invoice.
No. The file is read and analysed by JavaScript in your own browser tab and never sent anywhere. This page ships a Content-Security-Policy that blocks outbound connections entirely, so the browser itself prevents the page from transmitting your data even if it tried. There is no account, no sign-in and no server-side storage. Closing the tab is all the cleanup there is.
Work down the list by steps per run, because the top few rules usually account for most of the bill. Each pattern this page flags has a different fix.
Broad trigger, narrow condition. A rule triggered on Issue updated or Field value changed that then fails a JQL condition most of the time is paying for its trigger and its condition on every update, all day, to do nothing. Push the filter up into the trigger: restrict which fields it watches, or scope it to a project or issue type, so the rule stops starting rather than starting and stopping.
Uncapped branches. A branch over all issues in the project, or over a JQL with no bound on it, runs everything inside it once per matched issue. Put a limiting clause on the JQL, or move the work to a scheduled rule whose query returns a set you can predict.
Rule chaining. Rules that set fields other rules watch multiply quietly, and a loop between two of them bills both every time. Allow other rule actions to trigger this rule is off by default, so any rule with it on was switched on deliberately at some point — check whether that reason still holds.
Log actions. A log action costs a step per run and is nearly always left over from building the rule. Take them out once it works.
Two habits are worth more than any single fix. Order conditions cheapest and most selective first, so a rule exits before doing expensive work. And read your audit log for rules with a high proportion of No match or No actions performed — those are rules paying to decide they have nothing to do, and they are the cheapest steps you will ever recover.
None of this needs us. If you would rather not work through it alone, ReleaseTEAM can do it against your real execution history.
Saves this analysis as one branded, print-ready file you can keep or send on. Built in this tab, uploaded nowhere.
Patterns that tend to burn steps you didn't mean to spend, read off each rule's own structure. One row per pattern, with the rules that tripped it named underneath. The numbers are each rule's rank by steps per run, shared with the sections below, so they skip any rule with nothing flagged.
Trigger plus every condition, branch and action that fires on one successful run. Enabled rules only.
Drop in your Automation audit log and these counts come off your own history. Failing that, the file answers for the scheduled rules on its own, and the rest are yours to fill in.
automation-audit-logs-*.csv
| # | Rule | Steps/run | Runs/mo | Steps/mo |
|---|
That number is built from run counts you estimated. We can replace them with your real execution history and fix what is driving it.
Schedule an AssessmentCertified Atlassian Partner · 25+ years of DevOps delivery · Westminster, CO
We'll pull your actual execution history, find the rules driving your bill, and fix them before December 3. If you're not ready to talk yet, ask us for the readiness checklist and work through it yourself.
Certified Atlassian Partner · 25+ years of DevOps delivery · Westminster, CO