Automation Step Cost Calculator · for Jira & Confluence
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 only when it performs an action and ends in Success, Some errors, Failure or Loop; then every step that ran before it stopped is billed. Runs that Atlassian aborts or throttles, and failures on Atlassian's own side, are not billed. Rovo agent steps are billed separately, as Rovo credits rather than automation steps.
Since 5 November 2026, a run that stops before any action runs costs nothing. A rule that fires on every issue update and fails its condition ends as No actions performed, and neither its trigger nor its conditions count. A few components never count even when they run: Log action, Create variable, Create lookup table, Re-fetch work item data and Lookup work items.
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; on an existing Enterprise contract, current packaging holds until it renews. 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 busy rule doing more steps than it needs on every run that acts, 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 is never uploaded. Unless you untick the box under your report, we keep its numbers and percentages, rounded: rule, step and flag counts, the estimated cost, your plan tier and a seat band. We pool those to gauge industry norms, never rule names, never the file name, never the file itself, and no IP address. The report shows you the exact request before it is sent. This page's Content-Security-Policy blocks fetch, XHR and WebSocket connections, so that request is the only one that carries numbers. There is no account and no sign-in.
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. Since 5 November 2026, a rule triggered on Issue updated or Field value changed pays nothing for the runs its condition stops before any action. It does pay for that condition as a step of its own on every run that goes on to act. Where the filter can live in the trigger instead, by restricting which fields it watches or scoping it to a project or issue type, each of those runs costs one step fewer. That is worth doing on your busiest rules, and rarely worth making a readable rule harder to maintain.
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 and lookups. Log action, Create variable, Create lookup table, Lookup work items and Re-fetch work item data do not count as steps, so there is no billing reason to remove them. This page leaves them out of every figure.
Two habits are worth more than any single fix. Keep the runs that act as lean as the job allows, because those are the only runs that bill. And read your audit log for the rules that act most often, not the ones that stop most often: runs ending in No match or No actions performed are free now, so the steps worth recovering are in the busy rules that succeed.
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, less the components Atlassian does not meter. 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
Email me this summary
Sending shares only your email address and these headline numbers with releaseteam.com: estimated steps per month, estimated overage, rules analyzed and flagged, how many rules carry each of the five flags, your monthly step allowance, and your Jira and Confluence plans, all as numbers, never your file or any rule names. How we handle it
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