A Jira rule checks each priority change to see whether an incident is critical, then alerts the responsible team only when it is. Under the original Atlassian Automation usage-based pricing announcement, checks with no subsequent action would still have used the allowance. Since 5 November 2026, those runs no longer count.
Atlassian has responded to feedback on its first announcement. That is welcome news for teams that deliberately built maintainable rules around conditions and clear ownership. Usage, spending controls and operational consequences still need attention. This article reflects the position on 10 November 2026.
Then: What the Original Announcement Would Have Changed
On 1 September 2026, Atlassian announced that Automation usage would be measured in executed steps rather than simply rule runs. Triggers, conditions, actions, branches and loops form the new unit. Allowances from eligible apps are pooled across the organisation and refresh monthly.
The original plan would have counted steps in runs with no action, too. Frequent events could therefore have consumed the allowance simply by checking a condition. Teams might have felt pressure to combine or rebuild clear rules for cost reasons alone. A run with many executed actions would also consume more steps than a short one.
Our own Jira automations for a sales process illustrate why the distinction matters: conditions and separate actions represent different responsibilities in the process. Clear rules help teams maintain them and understand who owns what.
Now: No Action, No Usage
An example from the documentation: a trigger, separate condition and notification use three steps when the action runs. Putting the condition inside the trigger makes it two. The difference applies to runs that perform an action; if the run stops beforehand without one, both variants use zero.
In its 5 November update, Atlassian changed course. If a run stops before an action executes, neither its trigger nor its conditions count. The audit log records the status “No actions performed”. Usage recorded before 5 November remains unchanged.
In the example above, an update that fails the critical-priority condition and ends there consumes zero steps. If the rule sends a notification, relevant executed steps count. Depending on the flow, failed runs can still consume usage when an action has been performed. The Atlassian calculation guide sets out the exceptions.
There is no need to rebuild modular rules solely because of actionless checks. For runs that do perform actions, the number and placement of executed steps still matter. Actions inside loops count for each execution; some system steps, including log actions, are excluded.
More Visibility From December
Organisation admins can see overall consumption under Usage → Meters → Automation steps in Atlassian Administration. This compares usage against the shared allowance. The total alone will not identify the cause: one frequently running rule may account for a substantial share.
By early December, the Usage tabs in Jira, Jira Service Management and Confluence are expected to rank flows by step usage. Audit logs are planned to show steps per run and per executed step, and CSV exports to include step counts. The flow builder also shows estimated usage before activation. These detailed views are announced or rolling out, rather than guaranteed to be available everywhere already.
What Teams Still Need to Do
Sharing one allowance also raises a governance question: usage by one team leaves less available for others. Atlassian has not promised a separate budget per site in its 2027 announcement. Agree internally who reviews usage and follows up with the teams responsible.
The change removes one problematic incentive, while budget and operational ownership remain. The included allowance stays the same. Billing for usage beyond it starts on 3 December 2026, or at renewal on or after that date for Enterprise.
Pay as you go is enabled by default according to Atlassian. Organisation and billing admins can cap or disable extra usage. This is an operational choice: extra usage can generate charges; with it disabled, flows stop when the allowance is exhausted until the next reset. A spending limit also protects the budget at the potential cost of interruption. More granular organisation-wide controls are planned for 2027; details have yet to be announced.
- Check the organisation-wide allowance, usage and forecast under Usage → Meters now. Compare periods before and after 5 November separately.
- Agree with process owners which automations are critical and whether extra usage, a cap or an interruption is acceptable.
- From December, open the highest-usage flows in the Usage tab, inspect their audit logs and then optimise selectively. Pay particular attention to loops and frequent triggers.
- Check the billing date and terms for your own organisation. AI actions may consume Rovo credits separately.
Costs should be predictable without sacrificing maintainability. In our Atlassian licence management, we look at usage drivers and licensing options together before changing rules.
