Automation steps start billing on 3 December. Your allowance, what counts, and what burns it.

[#1]

On 3 December 2026 Atlassian Automation stops being free at the margin. It has already moved from per-app monthly run limits to automation steps pooled at the organisation level; from that date, steps beyond your allowance are billed (how usage is calculated). The meter has been counting in Atlassian Administration since 1 September, so you can read your real number today instead of guessing it in November. This is not a pricing explainer, the partners have written those. It is the admin's version: your allowance, exactly what counts, and the rule audit that keeps you under it. 🧮

Your allowance, per month, pooled

From Atlassian's table (per user per month on paid plans; per subscription on Free):

App	Free	Standard	Premium	Enterprise
Jira	150 per subscription	400	750	1,000
Confluence	50 per subscription	100	250	500
Jira Service Management / Service Collection	1,250 per subscription	3,000	6,500	9,500
Teamwork Collection	200 per subscription	2,500	5,000	7,500
Jira Product Discovery	100 per subscription	300	500	750

They add up across apps and share one pool. Atlassian's own example: 100 Jira Premium users (75,000) plus 100 Confluence Standard users (10,000) is 85,000 steps a month for everything. Two things to notice: Enterprise is an allowance, not unlimited, and JSM seats carry an allowance roughly nine times a Jira seat's, which is why a mixed org's service desk is usually funding its software automation.

What counts, exactly

A step is one executed component: a trigger, a condition, an action, an if/else branch, or one iteration of a loop. Atlassian charges a step when the component finishes with any of five statuses: SUCCESS, NO_ACTIONS_PERFORMED, SOME_ERRORS, ABORTED, and NO_MATCH. The last one is the sentence to underline: a trigger that fires and matches nothing is still one step. A rule that listens to "Work item updated" and rejects 95 percent of events pays for every rejection.

What does not count: system and synthetic components Atlassian runs on your behalf, THROTTLED runs where nothing executed, and system-side errors. And the Use Rovo agent family of actions bills as Rovo credits, a separate meter on the same page, not as steps.

Where to read the meter, and what it does not show

Atlassian Administration, Insights, Platform usage: the Automation steps meter, your total allowance, and consumption against it. Usage populates with up to a week's delay, so September is partial and October is the first clean month.

Per rule, the closest native view is Performance insights (a space's automation list, More actions, View performance insights; or the global automation page for every space at once), which shows execution counts and outcomes per flow (performance insights). It counts executions, not steps, so the arithmetic is yours: executions multiplied by the components in the rule, with loops multiplied again by items per run. It is enough to rank your rules, which is all the audit needs.

What happens over the line

Extra usage is on by default, billed in arrears at $0.50 per 1,000 additional steps (Atlassian's example: 10,000 steps over is $5.00), with notifications to org and billing admins at 80 and 100 percent (usage charges and billing). The sane setting is on with a monthly limit, so an overage is capped rather than silent. With extra usage off, hitting 100 percent stops every flow until your usage billing date, which is your subscription's date, not the first of the month; a 20 November overrun with a 3 December reset is thirteen days without automation. Whoever owns your rules should be one of the admins who gets the 80 percent email.

The six rule shapes that burn steps

1. The broad trigger with a narrow condition. "Work item updated" then "Field X changed to Y" fires on every edit in the space and fails most of the time, paying a trigger and a condition each time. Use the narrow trigger, Field value changed for that field.
2. The hourly scheduled sweep. Broad JQL, branch per matching item, every hour: a trigger, a branch step per item and its actions, whether anything changed or not. Tighten the JQL (updated >= -1h), lengthen the interval, or move the check to an event-driven rule.
3. Conditions in the wrong order. Conditions run in sequence and the first failure stops the count. Put the cheapest, most selective condition first: work type or space before a JQL condition.
4. The loop over a large set. Related work items and advanced branches charge every iteration. A rule that touches every child of an epic on every parent change is a loop you pay for per child, per change.
5. Rules that trigger each other. Rule A sets a status that triggers rule B, which edits a field that triggers rule A. The same event is paid two or three times. The audit log's "triggered by another rule" line is where to look; consolidating the chain into one rule is usually the fix.

6. Log actions on the happy path. A Log action is an action component and counts like any other, so a rule that logs at every step doubles its own cost for the privilege of being debuggable. Keep the log where it earns its step: after a Send web request, an if condition on {{webResponse.status}} outside the 2xx range, and the Log action inside that branch. On a good day the rule costs two steps; on the day the environment breaks, it costs three and you have the evidence. (Credit to @Becker_ Rene in the comments for pushing back on my first, blunter version of this advice.)

The audit, in an afternoon

1. Platform usage: note the allowance and this month's count.
2. Performance insights, global: sort by executions, take the top ten, name each one's shape from the list above.
3. Fix the top three; in my experience they are more than half of the total.
4. Read the meter again a week later. That delta is your December safety margin.

5. Then re-audit monthly, and keep the evidence. The automation audit log retains 90 days, so a chain that doubled your count in December cannot be reconstructed by March. In the first week of each month, screenshot or export Performance insights for every space with meaningful volume, that is the baseline the next audit diffs against, and the thing you hand Support if the meter and your arithmetic ever disagree. (Credit to @Maria Reisinger _MetaFrazo_  in the comments for the retention point.)

Still to come from Atlassian

Usage data export, monthly and committed usage packs, and per-group allocations are listed as planned by 3 December, not available today (usage-based pricing overview). Until export exists, executions multiplied by components is your only line-by-line view; plan the audit around that rather than waiting.

Verified against Atlassian's automation usage and billing documentation on 8 September 2026; rule shape 6 and the re-audit note added 10 September.

[Maria Reisinger _MetaFrazo_]

The step-shape list is the useful part. Most pricing coverage stops at the table.

One thing I keep thinking about after the audit: you fix the top three, and then what? Rules drift the same way schemes do. Someone widens a JQL, someone adds a branch, and the shape you fixed in October is a different shape by February. Nothing tells you it happened until the bill does.

Which is also why the rule-chain case is the nastiest one on your list. The evidence lives in the audit log, and that runs out at 90 days for automation. So the chain that quietly doubled your costs in December is not something you can reconstruct in March.

[Yong Yang]

Good automation practices are more important now, just like the neat codes.

[s_gridnevskii]

Looks like we will need to move most automations into workflow post functions. Hopefully Atlassian will not start charging for every workflow step.

[Rafa]

on every update, you just keep giving more reasons to migrate away from your platform...

when you eventually realise that all your ajax has a cost on your servers, will you start charging per letter typed on autocomplete fields?

also, your migration is already breaking. I got a notification saying i was reaching my limit of 5000 steps for the month, with only 80 left, under https://admin.atlassian.com/billing/...

yet under /jira/settings/automation#/tab/usage i see I barely used any automations in the 9 days of this month. If this is a way to warn me that my automation allowance will become useless in december, the messaging is very misleading, though it does show the automation feature is no longer useful for anything.

[Becker_ Rene]

I was wondering, if this is Atlassian's way to increase platform by either

- have users migrate to different automation solutions

- or users optimizing their flows.

Also ... its a bit unfair. Although you gain more usage because it's now working on org-level (so a standard license will benefit from another product with a premium) the growth is always exponentally. Instead of Runs, we now caluculate Runs * steps.

Also ... even unfairer: Because of the way flows are designed, we need to at least create more than 2-3 times the steps than in other systems if we want to use complex flows. And as far as I am aware, log nodes count as well. So if you want to compensate for the poor logging flows deliver by default, you'll be charged for thaem as well.

In total:

- Benefit for products with low licensing (if you have at least 1 premium license)

- Exponential rise in usage

From now on? Best way for us, is to have one-step workflows (hoping that triggers don't count) handing the trigger data over to another automation tool (webRequest) and have cronjobs run outside of Atlassian's platform (or again switch to different paid apps). WebHooks could also be a thing.

But I guess that option does not work for everyone though.

Waiting for the day, we have to pay per page in Confluence. -.-

---

[Sami Shaik]

@Maria Reisinger _MetaFrazo_ , both points are sharper than anything in the article, and the second one is a deadline I had not put together: the automation audit log keeps 90 days, so a chain that doubled the count in December is unreconstructable by March. That makes the December read of Performance insights an artefact to keep, not a page to glance at. Screenshot or export it in the first week of each month; that is the baseline the next audit diffs against.

On drift: the cheapest detector I know is a scheduled rule that does nothing but count. Once a week, a rule per space with a scheduled trigger and a single Log action that writes the date, then the admin compares executions per rule in Performance insights to last week's. It is manual, and it costs one step a week, which is the point. Until Atlassian ships the usage export they have listed for 3 December, the comparison is by eye. I will add a "re-audit monthly, keep the evidence" line to the article, because "fix the top three" without "then what" is exactly the gap you have named.

[Sami Shaik]

@s_gridnevskii ,

Post functions are not metered, so the instinct is right for one class of rule: anything that only ever fires on a transition (set a field, assign, clear a value, add a comment) belongs in the workflow, and moving those out of automation is the cleanest step reduction there is. Two limits worth keeping in view: post functions cannot react to anything that is not a transition (a field change, a comment, a schedule), and they cannot branch across other work items, so the rules that burn the most steps (scheduled sweeps, loops over children, chains) are exactly the ones that cannot move.

My rough split: transition-bound logic to the workflow, everything event-driven stays in automation with a narrow trigger. On whether workflow steps get metered later, that is Atlassian's to answer and I will not guess.

[Sami Shaik]

@Rafa , the discrepancy you describe is worth chasing rather than shrugging at, because the two pages you are comparing are not the same meter. /jira/settings/automation#/tab/usage is the space-level view for one Jira space's rules; the notification that says 5,000 with 80 left is the organisation meter in Atlassian Administration, Insights, Platform usage, which sums every space and every product's automation (Confluence, JSM, JPD) across the org. If other spaces or products are running rules, the org number will be far ahead of the one space you are looking at. If you open Platform usage and the per-product breakdown there still does not add up to the notification, that is a genuine mismatch and Support will want the screenshot of both, with the timestamp, because the meters only went live on 1 September and Atlassian says usage can take up to a week to populate.

On the pricing itself: I wrote the article so admins can measure it rather than be surprised by it, and I am not going to argue Atlassian's case for them. The one thing I would say is that a 5,000 allowance being nearly consumed on day 9 means something on your site is running hot, and the audit in the article will find it in an afternoon, whichever platform you end up on.

[Sami Shaik]

@Becker_ Rene , you are right that Log action counts; it is an action component like any other, so a rule that logs at every step doubles its own cost for the privilege of being debuggable. Two practical answers: log only inside failure branches and error paths, and strip the logs out once a rule has been stable for a month (the audit log records the outcome of every component anyway, so the Log action mostly duplicates it). On "runs times steps," that is exactly the change: a 20-component rule that ran once used to be one run and is now twenty steps, and the mixed-plan pooling you describe is real, it just runs the other way for orgs whose heavy automation sits in the low-allowance product. The one-step-workflow idea has the same limit I gave above: it works for transition-bound logic and not for anything event-driven or cross-item.

[Becker_ Rene]

> The one-step-workflow idea has the same limit I gave above: it works for transition-bound logic and not for anything event-driven or cross-item.

Why not?

When I trigger an event like "work item created", it can trigger a flow, which only has one step -> send to my external workflow engine.

...

While typing and re-reading the posts I am realizing something. I think I caused confusion with the vocabulary.

In my head:

Flow = Automation (as in flow => short for Workflow)

I didn't consider, that Workflow can also be the work item workflow (status, transition, ...)

Sorry :-)

Correction: I was talking about 1-Step Automations (Trigger + WebRequest)

---

> strip the logs out once a rule has been stable for a month

I'd like to. The thing is, that in my experience, the flow runs perfectly for months and all of a sudden something in the environment changed or wasn't available. And that's where I need the log the most.

---

[s_gridnevskii]

@Sami Shaik I recall that Data Center with Assets had an opportunity to run a groovy script for Post Functions. Sadly cloud does not allow it.

[Sami Shaik]

@Becker_ Rene , no apology needed; the vocabulary collision is Atlassian's, since "flow" is the new name for a rule and "workflow" kept its old meaning. With the correction, your design reads differently and I agree with it: trigger plus Send web request is the cheapest shape there is, two steps per event, and everything after that runs on your engine's meter, not Atlassian's. It is the right pattern for anyone who already has an orchestrator.

On the logs, you have changed my mind on the blanket "strip them" advice, so let me narrow it. The point that survives is do not log on the happy path, because the audit log already records every component's outcome, and for a web request that includes the response status and, if you tick the option, the response body. The point I concede is that a failure months later needs context the audit log alone does not carry. So the shape that costs nothing while the rule is healthy: Send web request, then an if condition on {{webResponse.status}} outside the 2xx range, then the Log action inside that branch (with the payload, the status and whatever smart values you need). On a good day the rule costs two steps; on the day the environment breaks, it costs three and you have the evidence. That is the version I will fold into the article's rule-shape list.

[Sami Shaik]

@s_gridnevskii , 

Correct, and it is the cleanest example of the gap: in Data Center a scripted post function did the transition-bound work for free, and in Cloud the built-in post functions are a fixed short list. The Cloud equivalent is a Forge app that registers a workflow post function, which runs on Forge invocation limits rather than the automation meter, so the logic can move out of automation, at the price of maintaining an app. For most teams the honest answer is the split I gave above; for the few with heavy transition logic and a developer, the Forge route is the one that is not metered in steps.

[s_gridnevskii]

@Sami Shaik in fact you do not need to check webresponse status. Just use body in smart function like {{#if(webresponse.body.match("(specific pattern)")}}result{{/}}

It may take some time to get used to, but many of my rules use this approch eliminating steps for branching.

I found it in archives as an example. It provides JQL to modify issues. No if else, nothing, just text functions.

{{#if(exists(issue.summary.match("SD\s*-\s*(\d+)")))}} KEY IN ({{issue.summary.match("(SD\s*-\s*\d+)").asJsonString}}) {{/}} {{#if(not(exists(issue.summary.match("SD\s*-\s*(\d+)"))))}} KEY IN (NEVERPROJECTWITHTHISKEY-1) {{/}}

I guess it is time to create tips and tricks section for tools to eliminate automation steps :)

[Sami Shaik]

@s_gridnevskii ,

That is a better shape than mine and I will take it: a smart-value conditional inside one component costs no step, where an if/else component costs one plus whatever runs inside it. {{#if(webResponse.body.match("pattern"))}}...{{/}} collapses the branch into the action that was going to run anyway, and your JQL example does the same for a lookup that would otherwise need a condition in front of it. For high-volume rules that is the cheapest branching there is.

One trade to name so nobody adopts it blind: the folded branch is invisible to the audit log. An if/else component records which branch ran; a smart-value conditional records only the action's outcome, so when a rule misbehaves months later you are reading the rendered text to work out which path it took. My rule of thumb after your comment: fold the branch into the action on rules that run hundreds of times a day and are stable; keep the visible if/else on rules that are complex, rarely run, or still changing. The tips-and-tricks section is a good idea; if you write it, I will link it from the article.