How Jira Automation steps are counted, and how to use fewer on notification rules

Updated October 21, 2026 by Pledona

Atlassian Automation no longer counts rule runs. It counts steps: every trigger, condition, action, branch and loop iteration that runs. From December 3, 2026, steps beyond your monthly allowance are billed. Notification rules, the ones that post to Google Chat or Slack or send an email on every change, are among the busiest rules on most sites. Here is how the meter works, how to estimate what your notification rules use, and how to bring the number down.

What counts as a step

Atlassian defines a step as one executed part of an automation flow (Atlassian's new name for a rule). Each of these counts once every time it runs:

• Triggers: the event that starts the flow, such as Work item created.
• Conditions: for example an Issue fields condition that checks priority, or a JQL condition.
• Actions: such as Send web request, Send email or Log action.
• Branches: If/else paths.
• Loops: each iteration of a branch over related or looked up work items.

Atlassian's own example: trigger, check priority, assign user, send notification is 4 steps. A step is charged when it ends as SUCCESS, NO_ACTIONS_PERFORMED, SOME_ERRORS, ABORTED or NO_MATCH. The last one matters most for notifications: a trigger that fires and matches nothing still costs one step, and a condition that fails costs one more. System components Atlassian runs for you, throttled runs where no step executed and system side errors are not charged. Rovo actions such as Use Rovo bill Rovo credits instead.

Monthly allowances

Allowances are pooled across your whole Atlassian organization and refresh monthly. Paid plans get an amount per user; Free plans get one amount per subscription.

So a site on Jira Free has 150 steps a month in total, while 10 Jira Standard users bring 4,000 steps into the pool. Enterprise is no longer unlimited.

What happens when you go over

• Extra usage on: flows keep running and extra steps are billed at $0.50 per 1,000 on your next invoice, starting December 3, 2026. Organization and billing admins get notices at 80% and 100%, and can set a monthly limit to cap the spend.
• Extra usage off: at 100% new flow runs stop until your allowance refreshes on your usage billing date, or until you buy a step pack. Atlassian says events that happen during the pause are not queued or replayed, and manually triggered flows pause too. For notification rules, that means messages that are simply never sent.

Where to read your usage

In Atlassian Administration, select Insights, then Platform usage to see steps used against your organization's allowance. To find which rules use the most, open the automation list and use Performance insights. An Atlassian Community admin guide points out that it counts executions, not steps, so multiply each rule's executions by the number of components that run in it. The same guide notes usage can take up to a week to show up.

Step math for a notification rule

A typical Google Chat rule is a trigger, a condition and a Send web request action. Take a project that creates 300 work items a month, 30 of them High priority, with a rule that only posts High priority work:

• Every new work item fires the trigger and runs the condition: 300 + 300 = 600 steps.
• The 30 that match also run the action: 30 steps.
• Total: about 630 steps for 30 messages.

Now the same idea on Work item updated with a condition such as "priority changed to High". If the project sees 3,000 edits a month, the trigger and the condition run on every edit: over 6,000 steps, almost all of them for edits that send nothing. On Jira Free, 150 steps covers about 50 messages from a three component rule, and less once non matching events are counted.

How to use fewer steps on notification rules

1. Use the narrowest trigger. Prefer Work item transitioned with the from and to statuses you care about, or Field value changed for the one field you watch, over Work item updated plus a condition. A condition never stops the trigger from being charged.
2. Put the cheapest, most selective condition first. Conditions run in order and the first failure ends the run, so check project or work type before anything else. Atlassian suggests the Issue fields condition before JQL where it can do the job.
3. One rule per event, not one per space. If two Chat spaces need the same event, one rule with two Send web request actions pays for one trigger instead of two triggers and two conditions.
4. Build digests without a loop. A scheduled rule that branches over every matching work item pays per item, every run. A scheduled trigger with no JQL of its own, one Lookup work items action and one message that lists {{lookupIssues}} costs three steps per run, about 90 a month for a daily digest. If you put the JQL on the scheduled trigger instead, the actions run once per matching work item. Lookup work items only returns the first 100 results, so keep the JQL tight (for example updated >= -1d). Our daily digest guide has the rule.
5. Log only on failure. A Log action is an action and costs a step. The audit log already records each component's outcome, so keep logging inside a branch that only runs when the web request fails.
6. Break rule chains. A rule that edits a field which triggers another rule pays for the same change twice. Look for "triggered by another rule" in the audit log.
7. Turn off what nobody reads. A Chat space that muted the bot months ago still costs steps on every event.
8. Use Jira's built in notifications where they fit. Email notifications from your project's notification scheme are not automation flows and use no steps.

Moving notifications off the meter with an app

Be honest with the math first. At $0.50 per 1,000 extra steps, a paid site with room in its pool usually saves more by tuning rules than by buying anything. An app makes sense when the allowance is small, as on Jira Free with 150 steps for the whole site, when extra usage is turned off and a hard stop would silence alerts, or when you need features a webhook rule lacks.

Marketplace apps built on Atlassian Forge react to Jira events and schedules through their own Forge triggers rather than automation flows, so their work does not draw on your automation steps. Two of ours replace common notification rules:

• Threadline for Jira posts Jira and Jira Service Management updates to Google Chat with routes by project, event, issue type, priority, status, labels, assignee or JQL, one thread per issue, batching, daily digests and quiet hours, and a delivery log. See the Threadline documentation. Free for up to 10 users, then $0.80 per user per month through Atlassian, and pending Atlassian Marketplace review.
• Pledona Export for Jira can replace a scheduled "email me a report" rule: a saved filter or JQL runs daily, weekly or monthly, the Excel, CSV or PDF file is attached to a Jira work item you choose, and Jira notifies the people you pick. Free for up to 10 users, then $1.50 per user per month through Atlassian, and pending Atlassian Marketplace review.

Sources: Atlassian Support, How is your automation usage calculated and Jira automation conditions; Atlassian, Atlassian Automation licensing FAQ; Atlassian Community, Automation steps start billing on 3 December. All checked October 21, 2026.

Frequently asked questions

Related guides

• How to format Jira Automation messages for a Google Chat webhook
• How to send Jira notifications to Google Chat
• How to post a daily Jira digest to Google Chat
• How to schedule Jira reports by email
• How to send Jira Service Management alerts to Google Chat