SAP
AMS
Atlassian
Products
Industries & Expertise
BEST-SHORING
Knowledge Base
SALESFORCE
Atlassian’s new usage-based pricing model has understandably drawn attention for its treatment of Rovo credits and AI features. For many Jira Enterprise administrators, however, the more immediate operational change is elsewhere: Jira Automation is becoming metered.
From 3 December 2026, Atlassian will measure Automation usage in executed steps. Enterprise subscriptions will no longer have unlimited Automation. Instead, eligible subscriptions contribute to a shared, organisation-level monthly allowance, with additional capacity available through prepaid packs or postpaid usage at US$0.50 per 1,000 steps.
This is not a minor licensing detail. Automation is often embedded in the operational fabric of Jira: assigning work, enforcing standards, sending notifications, synchronising fields, creating follow-up work, managing approvals, escalating service requests, and keeping complex workflows moving. For mature Jira environments, the question is not whether Automation is valuable. It is whether the organisation understands how its rules consume usage, which flows are genuinely business-critical, and what happens when the shared allowance is exhausted.
Previously, Atlassian measured Automation through successful rule runs. A simple rule and a complex rule each counted as one successful run, regardless of the number of conditions, branches, actions, or loop iterations inside the rule. Enterprise customers had unlimited Automation under that model.
The new approach counts Automation steps. A step is an individual executed component of a flow: a trigger, condition, action, branch, or loop iteration. Atlassian’s own example—a trigger, a priority check, an assignment, and a notification—consumes four steps.
This means two rules that look similar in an audit log can have very different consumption patterns. A rule that checks one condition and updates one field may use only a few steps. A scheduled rule that searches across many issues, branches into multiple paths, loops through related items, and sends several updates can consume a much larger number of steps each time it runs.
The change also introduces a pooled model. Allowances from eligible Jira, Confluence, Jira Product Discovery, Jira Service Management, and collection subscriptions are combined at organisation level. This gives teams flexibility across products, but it also means one high-volume use case can affect the capacity available to everyone else.
The key risk is not that every automation rule will suddenly become expensive. The risk is a lack of visibility. Many Enterprise sites have accumulated rules over years, often across multiple projects and teams. Some are well designed and actively maintained. Others were built to solve a temporary problem, then forgotten. Some run only when a human changes an issue. Others run on schedules, react to high-volume events, or loop through large sets of work.
Under step-based metering, complexity and frequency matter together. A complex rule that runs rarely may have negligible impact. A moderately complex rule that runs every few minutes across thousands of issues may become a major consumer. Scheduled rules deserve particular attention because they can consume steps even when they find nothing useful to process.
There is also an operational continuity issue. If a pooled monthly allowance is consumed and extra usage is disabled, new automation flows stop executing until the next billing period starts or additional capacity is added. Events are not queued for replay when the allowance refreshes. Flows that are already in progress can complete, but trigger events that occur during the pause are not stored for later execution.
That is why this change should be treated as a service-management and process-governance task, not simply as a finance exercise.
The distinction between a rule run and a step is the most important concept for administrators to communicate.
Consider a simple onboarding rule. A new employee request is created, the rule checks that the request type is correct, assigns it to a team, creates a linked task, and sends a notification. Even without branches or loops, multiple steps are executed.
Now consider a scheduled hygiene rule. Every hour, it searches for all overdue requests, loops through each request, checks its priority and customer tier, adds a comment, updates a field, notifies an owner, and possibly creates an escalation task. The total consumption depends on the number of matching requests, the logic executed for each one, and the frequency of the schedule.
The second rule may be highly useful. The point is not to remove it by default. The point is to make its consumption and business value visible, then decide whether the design is proportionate.
The new pricing model does not punish automation. It exposes which automation patterns are high-frequency, high-complexity, or poorly maintained.
Atlassian is providing usage visibility through the Platform usage dashboard in Atlassian Administration, including monitoring and alerting as organisations approach their allowance. Begin with the available data rather than estimating from the number of rules alone.
Identify the apps, projects, and periods where usage is highest. Review trends rather than relying on a single quiet week. Seasonal processes, release cycles, quarter-end activity, and support peaks can significantly change the baseline.
Rules initiated by high-volume events deserve early attention. This can include frequent issue updates, status transitions, form submissions, comments, inbound service requests, and integrations that update many records.
Scheduled rules need a separate review. Ask what they search, how frequently they run, how many items they evaluate, and whether they still need to run when no meaningful change has occurred. Where appropriate, replace broad polling patterns with event-driven triggers or reduce the scope and frequency of the schedule.
Branches and loops are useful features, but they are consumption multipliers because they execute logic repeatedly. A loop across linked issues, affected services, participants, or a large JQL result set can cause step usage to scale quickly.
Look for rules that perform the same update or notification multiple times. Simplifying a sequence, narrowing a JQL query, placing conditions earlier, or consolidating actions can reduce unnecessary execution without changing the business outcome.
Atlassian does not currently offer a way to mark one flow as “business critical” for prioritised execution if an allowance is exhausted. This makes governance more important. Administrators need to know which flows support customer commitments, incident response, security processes, regulatory evidence, or financial operations, and which primarily improve convenience.
Document the owner, purpose, impact, and fallback procedure for critical rules. If a critical automation flow pauses, who notices? What manual process takes over? How quickly can extra capacity be approved or a usage pack added? These questions should be answered before an actual interruption occurs.
Atlassian allows organisations to purchase prepaid Automation step packs or enable postpaid extra usage. Extra usage is charged at US$0.50 per 1,000 steps. Neither option is automatically right for every organisation.
Teams with predictable, business-critical Automation may prefer capacity planning and committed packs. Teams with variable but non-critical usage may choose controlled postpaid consumption. In either case, establish who can change the setting, who receives alerts, what threshold triggers review, and who owns the budget.
The aim is not to create friction around every step. It is to ensure that a shared operational capability has an intentional owner and a clear decision process.
Do not start by deleting every complex rule. Complexity is not a defect when it reflects a valuable business process. Do not rely on a one-time review either. Automation changes as teams create new projects, add integrations, redesign workflows, and adopt new apps.
Avoid treating the allowance as an IT-only concern. Project administrators and business teams often own the rules that consume the most steps. They should understand why frequency, loops, and broad searches matter, and they should be involved in deciding what to optimise.
Finally, do not wait for an 80% usage notification before beginning. Alerts are an important control, but they are not a replacement for knowing the rules and processes that matter most to the organisation.
Atlassian’s move to step-based Automation pricing changes the management conversation. Enterprise teams are moving from an unlimited model to one that makes usage, design choices, and operational priorities visible.
The right response is not panic and it is not a blanket ban on Automation. It is a disciplined audit: establish a baseline, understand what drives consumption, remove waste, protect critical workflows through planning, and give both technical and business owners clear accountability.
Teams that complete that work before 3 December will be better positioned to control cost and avoid interruption. More importantly, they will emerge with a Jira Automation estate that is simpler, more intentional, and easier to operate.
If you need a second pair of eyes on your Automation estate, Lupus Consulting can help you map consumption drivers, review rule design, prioritise critical flows, and establish a practical governance approach before the new model takes effect. Get in touch with our team to talk through your next steps.
Most organisations do not lack strategy. They lack a live, reliable connection between
Moving from Opsgenie to Jira Service Management is more than a data migration. It is an
Many organizations invest heavily in Atlassian licenses and implementation, only to end