Update, November 6, 2026: On November 5, Atlassian changed how the meter counts. A flow run that stops before any action runs no longer counts toward your usage, trigger and conditions included. That removes the biggest cost driver in this post, the runs that filter out and do nothing, so as promised below I have reworked the worked examples, the section on filtering at the trigger, and the measurement advice. Where the September version said something different, I say so in place.
Before I dedicated myself to I.T., I had studied computer engineering. It made sense at the time. I was the first person in my family in more generations than we can remember to go to college, and was good at programming, so of course that was the way to go. No, I had no clue what a computer engineer even did. And, objectively, I was a terrible engineering student — though whether that’s because of the undiagnosed ADHD or the fact that it wasn’t really what I wanted is an open question.
But I still managed to get to my first assembly class. I still own the textbook for it. As I learned it, and how it related to the machine code underneath, it felt good to be good at something naturally, and it had been a long moment since I felt that. Yes, I had been learning programming in one form or another since I was 12, so maybe it shouldn’t have been surprising, but it was nice.
Some of the exams and homework were rote programming: given a task, complete it in the language. But for multiple-choice questions, one popular task was this: given a snippet of code, how many operations will it take to run? Those start simple, count the instructions. But some instructions require multiple cycles to complete, and that’s before we take into account the branch situations that can lead to looping or skipping portions of code. With each new topic, this rather simple question became more complex, and it became more real to us that instruction count was rarely a good indication of execution count.
That was also clear in the LinkedIn Post I shared around one of my favorite casual games: Human Resource Machine, where you again are given a very similar instruction set and very similar tasks, with challenges for completing it within a given task count and execution count. Is it sad this counts as a casual game for me?
So it shouldn’t be any surprise that last week’s UBP announcement from Atlassian had me cracking my assembly textbook for the first time in 20+ years. As I said last week, it’s going to be important to you to audit your rules. I stand by that recommendation, so this week I want to do the math. By the end of this, you should be able to open any rule in your instance, read it, and come out with a monthly step count you would be willing to defend in a budget meeting.
A caveat before we get into it. This is all still new, Atlassian’s documentation is still being written, and what follows is my best current understanding rather than settled fact. Last week I got a claim wrong about how AI actions are metered, and Atlassian corrected me within a day. Take that as fair warning: I can be wrong about this, and on something moving this fast I probably will be again. Where better information turns up I will update this post and note what changed, so it may be worth coming back in a month to see what has moved. That being said, we are 85 days out as I write this, which is precious little time to audit your automation flows. I may be wrong on details, but I am not wrong about the shape of this, so it is worth reading through and getting started today.
The Meter Now Counts What Runs, Not What You Built
Jira Automation has always had some natural limits. Beyond the caps that were implemented in late 2023, you’ve always had hard rules for how many “instructions” you could fit in a given flow: 65 conditions, branches, and actions in a standard rule, 500 in an advanced rule. These limits are equivalent to your program in assembly, and directly determine your program size. And to be clear, nothing about these limits changes this December 3rd.
But much like Human Resource Machine, Atlassian is adding a second value we need to consider: “execution” steps. Atlassian’s documentation defines an automation step as a single executed part of the automation flow, and five component types count: triggers, conditions, actions, branches, and loops. Of those, I think the trigger is an understandable addition, but also the most insidious: we’ll talk about that in a moment. Each execution of each one is a step. In turn, a component that sits in a rule but never runs on a given execution costs you nothing on that execution.
Excluded are the system and synthetic components Atlassian runs on your behalf, and anything with a THROTTLED status. Agentic components are excluded as well, which is something I can say with more certainty than I could last week. After last week’s post went up, Atlassian reached out directly to confirm that AI actions in automation do not count toward automation steps. A Use Rovo or Use agent action draws down Rovo credits instead, and the rest of the rule around it, trigger and conditions and ordinary actions and branches, still counts as steps normally. There is no double charge on the AI action itself. Credit where it is due, they read a fairly critical post and came back with a helpful answer rather than a complaint. I have not found that written on any support page, so until they publish it, consider this paragraph the citation.
Then there is the part that changes the math more than the counting rules do. When I wrote this in September, Atlassian’s documentation charged steps whenever an execution ended in any of five statuses: SUCCESS, NO_ACTIONS_PERFORMED, SOME_ERRORS, ABORTED, and NO_MATCH. A run that fired and got filtered out by a condition still cost you its trigger and every condition it evaluated, and most of the original version of this post was built around that.
Atlassian changed that on November 5, after customer feedback on exactly this point. Now, if a flow run stops before any action runs, none of its steps count: not the trigger, not the conditions. Those runs show up in the audit log as “No actions performed.” A run that performs even one action still pays for every step it executed, including every condition it evaluated on the way. So the meter is back to charging for work performed rather than work attempted, which is the model I said in September we were leaving. Usage recorded before November 5 stays as it was.
So the number you want is not the size of the rule. It is the cost of the path the rule took, averaged over every time it ran. Open a rule, count the boxes on screen, multiply by last month’s runs, and you will produce a figure that, like an AI hallucination, is confidently incorrect. It can be either too high, when a condition near the top kicks most runs out early, or too low, when one branch component is doing forty items’ worth of work every time it fires.
One naming note before the arithmetic. Atlassian has moved its vocabulary from “rules” to “flows,” and this is in the product rather than only the documentation: the button on my own instance now reads Create Flow, and the usage screen is documented at System → Automation flows → Usage. I am going to keep saying “rule” through the worked examples, because that is still what most of us say out loud, and the counting model underneath is identical either way.
The Formula, and the Four Numbers It Needs
Here is the whole method. For a single rule:
Monthly steps = executions per month × average steps per execution
The second term takes the work, because a rule does not have one cost. It has a cost per path:
Average steps per execution = Σ (share of runs taking that path × steps on that path)
Steps on the path = 1 for the trigger + every condition evaluated + every action performed + 1 per branch or loop component + (items in the branch × components inside it), and 0 for any path that ends before an action runs
That gives you four numbers to find:
- E, executions per month. Fixed by the schedule on a scheduled rule; from the audit log on an event-triggered one.
- P, the share of executions that make it past each condition. This is the hit rate, and it is usually the number nobody knows.
- N, the average number of items a branch or loop resolves to. Not the maximum. The average, over a typical month.
- C, the components on each path.
That is a dynamic instruction count with different units. E is the loop count, the path cost is the loop body, and P is the fraction of iterations that ever reach the expensive part. The three examples below are the same formula run three times, and each one goes wrong in a different place.
Worked Example One: The Runs That Did Nothing Are Now Free
Take an ordinary rule.
- Trigger: work item transitioned
- Condition: work type is Bug
- Condition: priority is Highest
- Action: notify a channel
- Action: set a field
- Action: add a comment
Six components on screen. Now count the paths.
A run where the work item is not a Bug evaluates the trigger and the first condition, then stops. Under the September rules that was 2 steps; since November 5 it is 0, because no action ran. A Bug that is not Highest evaluates the trigger and both conditions: 3 steps before, 0 now. A run that passes everything costs 6 steps either way.
Say that space sees 5,000 transitions a month, a fifth of them on bugs, and a tenth of those bugs at Highest priority:
| Path | Runs | Steps evaluated | Billed, September rules | Billed since November 5 |
|---|---|---|---|---|
| Not a Bug | 4,000 | 2 | 8,000 | 0 |
| Bug, not Highest | 900 | 3 | 2,700 | 0 |
| Full execution | 100 | 6 | 600 | 600 |
| 11,300 | 600 |
In September, about 71% of what this rule cost was spent on runs that did nothing at all. Since November 5 that share is zero, and the rule costs exactly what its 100 useful runs cost. Counting the boxes and multiplying, 5,000 × 6 = 30,000, was already nearly three times too high in September. Against today’s meter it is fifty times too high, which is the best argument in this post for working out the path costs rather than eyeballing the rule.
That rule is a reasonable rule, and nobody built it badly. In September I said its broad trigger was about to get a price. As of November 5 it doesn’t: a trigger that fires far more often than the thing it cares about happens only costs you on the runs where something actually happens.
Worked Example Two: A Branch Charges You Per Item
Now the opposite error.
- Trigger: an epic transitioning to Done
- Branch: on the epic’s children
- Condition: check if the child is still open
- Action: transition the child to Done
- Action: add a comment
Five components on screen. Under today’s model that is one run, no matter how wide the epic is.
Under the step meter, with an epic averaging twelve children of which three are typically still open: trigger, 1. Branch component, 1. The condition inside the branch runs against every child, so 12. The two actions run only on the children that passed, so 3 × 2 = 6. Twenty steps for one execution. Two hundred epics a month closes out at 4,000 steps, where counting boxes would have given you 1,000.
Notice that the condition inside the branch is charged on all twelve children while the actions are charged on three. That asymmetry is the lever here. If the branch can be scoped by JQL so that it only ever returns open children, you pay 1 + 1 + (3 × 3) = 11 instead of 20, and the rule does exactly the same thing.
The wider problem with this shape of rule is that N belongs to your data rather than to you. A branch written against a space with a dozen children per epic behaves very differently against one that has grown to fifty, and nobody will have edited the rule in between.
The November 5 change barely touches this example. Every epic that still has an open child performs an action, so the whole run is billed, including the condition on all twelve children. The only run that gets cheaper is an epic that closes with nothing left open: no action runs, so it should now cost nothing. I have not yet confirmed how the audit log records a branch where nothing inside it acts, so treat that last part as my reading of the announcement.
Worked Example Three: Polling Stopped Being the Expensive Habit
The third shape is a scheduled rule with a JQL trigger, and in September it was the one I would have gone looking for first.
- Trigger: Scheduled, every 15 minutes, with JQL, say
status = "In Progress" AND updated <= -5d - Branch: on the work items the JQL returned
- Action: Add a comment nudging the assignee
- Action: Add a “stale” label
- Action: Send a notification to the assignee
A rule on a fifteen-minute schedule runs 2,880 times in a thirty-day month. Give it a JQL trigger that finds something roughly 5% of the time, a branch, and the three actions above applied to each item it finds. Call it 430 items handled across the month. The work costs 430 × 3 = 1,290 steps. Under the September rules, the polling cost 2,880 triggers plus a branch on the 144 runs that found anything, which is 3,024 steps, so roughly 70% of the rule was looking around and finding nothing. Since November 5, the 2,736 empty polls cost nothing. What is left is the trigger and the branch on the 144 runs that found work, 288 steps, plus the 1,290 for the work itself: about 1,580 steps a month, down from about 4,310.
Now change nothing except the schedule:
| Schedule | Executions | Runs that found work | Monthly total, September rules | Monthly total since November 5 |
|---|---|---|---|---|
| Every 15 minutes | 2,880 | 144 | ~4,310 | ~1,580 |
| Hourly | 720 | 110 | ~2,120 | ~1,510 |
| Every 4 hours | 180 | 60 | ~1,530 | ~1,410 |
The work term is 1,290 on every row, because the same items still get handled. In September the polling was what moved, and going from a quarter-hour schedule to a four-hour one cut the rule’s cost by about 65%. Since November 5 the same change saves about 170 steps, roughly 11%, because the empty polls you would have been cutting are already free. The only polling overhead left is a trigger and a branch on each run that finds work, and slowing the schedule just batches the same items into fewer of those runs. So set the schedule for how quickly the work needs to happen, not for the meter. SLA escalation can stay at fifteen minutes. Stale-label cleanup can still go overnight, because nobody notices the difference, not because it saves you much.
Filtering at the Trigger Is No Longer the Big Lever
In September, this section argued that a condition which filters out a run still costs you the trigger and the condition, so every rule built as “trigger broadly, then narrow with a condition” was about to start costing you, and the fix was to move the filtering into the trigger. Since November 5 that is mostly moot. A run that a condition filters out performs no action, so it costs nothing, exactly like a trigger that never fires. The 8,000 steps Example One spent on transitions it did not care about are gone either way, and you do not have to rebuild the rule to get there.
Scoping triggers tightly is still good hygiene, and there is a small saving left in it. On a run that does go on to act, every condition it evaluated is billed, so a condition doing work the trigger could have done costs one step on each useful run. In Example One that is at most a step or two on each of the 100 full executions, not 8,000. In September I said my old habit of narrowing in the next step instead of the trigger seemed foolish. It is mostly harmless again.
The created >= -30d order by created DESC query I recommended here is still worth running on your own instance, but it means something narrower now. It is no longer a floor for every rule on the work item created trigger, because a created rule whose condition filters most work items out only pays for the ones it acts on. It is the floor for rules that act on every work item they see, and anything in a space you cannot browse is missing from the count.
Scope is the open question there. A rule scoped to one space should only run for that space, and today’s audit log behaves that way. I would expect that to hold under the meter, which would make your in-space creation rate the number that matters rather than the instance-wide one. I could not find anything in the documentation that confirms it, and of everything I could not settle, it is the answer I want most.
Work item created is still the trigger that takes no scoping of its own. Work item transitioned can be scoped to a single transition, and field value changed can be scoped to a field, but created takes nothing. The builder offers a condition right there on the trigger card, JQL or work item fields or user, which looks like filtering at the trigger and is not: those are ordinary condition components drawn next to the trigger. In September that meant filtering there cost two steps per creation rather than one. Since November 5 it costs nothing on the creations it filters out, and one extra step on each creation the rule goes on to act on.
The naked ones are where the bill actually is now. On work item created, set a field, add a label, assign it. That rule acts on everything, every execution is billed, and the cost is just the size of the workload. Two pieces of September’s advice survive intact for rules like that. Scope tightly, so the rule watches the fewest spaces it can. And merge rules that share a trigger and all act on it, because three created rules in one space that each set something buy three triggers per work item, where one rule holding all the actions buys one. Condition order matters less than I said: runs that exit early are free whatever order the conditions are in.
What To Do With Twenty Minutes and the Audit Log
When I wrote this in September, you could not measure any of it: the usage screen on every instance I checked still reported runs, the old unit. That has changed. By the end of October the Usage screen was showing estimated automation steps with a per-flow breakdown, as I noted in my Smart Checklist review. Atlassian says that by early December each app’s Automation Usage tab will rank flows by steps used over the current billing period or the last 30, 60, or 90 days, the audit log will show how many steps each run and each component in it used, and audit log CSV exports will carry step counts. The flow builder is also starting to estimate how many steps a flow is likely to use before you turn it on.
Until those land, the practical method still combines a measured number with a counted one:
- Pull E from the audit log. Executions per rule for a full calendar month is real data and it is already there.
- Read the rule and hand-count the cost of each path that ends in an action. Paths that stop before any action now cost zero.
- Estimate P from the audit log too. Runs marked “No actions performed” are your free runs; the rest are the ones you pay for.
- Estimate N by opening two or three of the work items the branch ran against and counting.
- Multiply, sum, and compare against seats × your per-plan allowance, remembering the allowance is pooled organization-wide now, so your “Just Jira” rules and your JSM rules draw on the same number.
Twenty minutes gets you through your five oldest rules, which is where I would start, because the rules nobody has edited in two years are the ones whose N has grown the most without anyone deciding it should. I put together a spreadsheet that does the arithmetic, so you are filling in E, P, N and the component counts rather than doing the sums by hand. Download the audit spreadsheet here. It was built on the September counting rules, so it still charges the paths that stop before an action; set those paths to zero steps when you fill it in.
One honest caveat. Every worked example above is my arithmetic against Atlassian’s published definitions rather than a number Atlassian has quoted. In September there were two mechanics I could not settle from the documentation, and the November 5 change settled one of them: a scheduled trigger that returns nothing performs no action, so it costs nothing. The other is still open. I do not know whether the branch component itself is charged once per execution or once per item, and I have assumed once per execution throughout, so the real numbers can only be higher. I also have not confirmed how a run is recorded when a branch executes but nothing inside it acts; I have assumed it counts as “No actions performed” and is free. Once per-run step counts reach the audit log in December, both should be checkable, and if you check them before I do, tell me and I will correct this post.
Wrapping Up
Every rule on your instance has always had a static count and a dynamic count. The static one is what you see when you open it, it is what the service limits have always governed, and it has never cost you a thing. The dynamic one is what executes on the runs that actually do something, and on December 3 it becomes the line item. Most of us have never had a reason to know that second number for a single rule, which is why the first one you work out is going to surprise you.
Three things to do with that, in the order I would do them now. Open your rules, sort by last modified oldest first, and take the top five: write down how many times each ran last month and how many of those runs actually performed an action, because since November 5 those are the only runs you pay for. Then look hardest at the ones that branch or loop over a result set, because the cost of a run that acts scales with your data. Then go looking for rules that share a trigger in the same space and all act on it, because merging those is still the cheapest fix in this post.
That is an afternoon’s work, and December 3 is not moving. I would like to know whether the most expensive rule turned out to be the one you would have guessed.
Until then, this is Rodney, asking: have you updated your Jira issues work items today?
Enjoyed this one? These posts are free and always will be — but if this saved you a headache or taught you something worth keeping, you can drop a tip in the Ko-fi jar. No paywall, no subscription, no catch. Just a thanks if the writing earned it.
→ Support The Jira Guy on Ko-fi
Discover more from The Jira Guy
Subscribe to get the latest posts sent to your email.
2 Comments