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 five 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.

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.

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 the three Atlassian pages linked above on 8 September 2026. Allowances, prices and the planned controls are Atlassian's to change; read the meter, not this article, when you budget.

[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.