Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

How do multiple conditions count towards the new automation step usage?

Dayna Portillo
Contributor
September 8, 2026

After receiving the notification about Atlassian's new automation pricing, I am on a mission to make my automations more efficient so we don't exceed our limit.  I am a bit unclear on how Atlassian is defining a "step" as it relates to conditions.  If a condition (yellow) step/node has multiple criteria that are connected by ANDs/ORs (JQL or otherwise), does that count as a single step or one step per criteria?  Similarly, within a trigger step, does each criteria/condition within that trigger count as its own step or is the entire trigger counted as a single step regardless of the number of criteria within it?

 

I found this article to be somewhat helpful but it did not fully answer my question regarding conditions: https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/Automation-steps-start-billing-on-3-December-Your-allowance-what/ba-p/3285795

 

Does anyone have any firm information on this topic?

3 answers

1 accepted

0 votes
Answer accepted
Sami Shaik
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
September 9, 2026

@Dayna Portillo , 

@Gor Greyan has the principle right and I want to add the source and the two cases it does not cover, because the difference between "I think" and "the doc says" matters when you are budgeting for December.

The unit is the component that executes, not the criteria inside it. Atlassian's definition: a step is a trigger, a condition, an action, an if/else branch, or one iteration of a loop, counted when that component finishes with a charged status (how usage is calculated). So:

  • One condition component with three criteria joined by AND or OR is one step, whatever the criteria evaluate to.
  • One trigger with several criteria (a field-changed trigger watching four fields, a scheduled trigger with a JQL) is one step per firing.
  • Three separate condition components in a row are three steps, and that is the case where rule design changes the bill: put the cheapest, most selective condition first, because a failing condition stops the run there and the components after it are not executed and not charged.

A failing condition still charges for itself. The charged statuses are SUCCESS, NO_ACTIONS_PERFORMED, SOME_ERRORS, ABORTED and NO_MATCH. A rule that fires on "Work item updated" and fails its condition 95 percent of the time pays one trigger step plus one condition step on every rejected event. That is the single largest source of unexpected steps I have seen, and the fix is a narrower trigger (Field value changed for the specific field) rather than a broader trigger with a condition behind it.

Not charged: system and synthetic components Atlassian runs on your behalf, THROTTLED runs where nothing executed, and system-side errors. Rovo agent actions inside rules bill as Rovo credits, not steps.

Verify it on your own rules rather than take anyone's word, including mine: open a space's automation list, More actions, View performance insights (or the global automation page for every space), which shows executions per rule and their outcomes (performance insights). It counts executions, not steps, so multiply by the number of components that ran; for a rule whose condition fails most of the time that is executions times two. Compare the total with the Automation steps meter in Atlassian Administration, Insights, Platform usage, and the arithmetic will tell you whether your reading matches the meter's.

@Trudy P Claspill  link is the same page; the section titled "What counts as a step" is the one to bookmark. I wrote up the allowance table, the charged statuses and the five rule shapes that burn steps in one place yesterday, if the long version is useful: Automation steps start billing on 3 December.

Dayna Portillo
Contributor
September 9, 2026

I appreciate your thoughtful and thorough response!  I was hopeful but didn't want to assume.  I read the documentation closely but it was never stated explicitly, and the word "conditions" can be a bit vague whether it refers to the entire condition node or each criteria within (I often use the word "conditions" in place of "criteria").  You're exactly right -- being wrong would be very costly so I needed certainty.  I will track my rules in the coming days!  Thanks again!

1 vote
Trudy P Claspill
Community Champion
September 8, 2026

Hello @Dayna Portillo 

Take a look at this document that comes from Atlassian.

https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/

I believe the relevant section is the one that starts with "A step is charged if it's execution results..."

0 votes
Gor Greyan
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
September 8, 2026

Hi @Dayna Portillo

@Trudy P Claspill has already provided the correct Atlassian documentation.

To clarify your specific question, Atlassian counts the Automation component that executes, not each individual criterion inside that component.

So, if one condition contains multiple criteria connected with AND/OR, it is still one condition step, not one step per criterion. The same principle applies to criteria configured within a trigger.

However, if your rule has multiple separate Condition components, each condition that executes counts as its own step. Actions, branches, and loops are similarly counted when executed.

So for optimization, it can make sense to combine related conditions where practical and place restrictive conditions early in the rule to prevent unnecessary downstream steps from executing.

Regards,
Gor

Dayna Portillo
Contributor
September 9, 2026

Thanks, Gor!

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin Site Admin
TAGS
AUG Leaders

Atlassian Community Events