Find the automation rules eating your step allowance

How steps are counted

Watch this from 1:03

An automation step is any part of a flow that runs: the trigger, each condition, each action and each branch. Atlassian's own example is a trigger, one condition and two actions, which is four steps.

Branches are where steps pile up. A branch over five child work items, with three actions inside, is fifteen action steps plus the branch itself.

Watch out. Before, a run only cost something if it did something. Now every step that runs counts, so a flow that starts on every edit and then finds nothing still spends its trigger and every branch it enters.

The allowance is pooled across the whole organization: every app and every site draws from one monthly pool, and unused steps do not roll over. Paid Jira plans include 400, 750 or 1,000 steps per user per month, by plan. Extra steps are charged per 1,000, extra usage is on by default, and admins get alerts at 80 and 100 percent. Billing for extra steps starts on 3 December 2026, or at your first renewal after that date. Sources: Atlassian, How is my usage calculated? and usage-based pricing.

Find the noisy flow

Watch this from 2:37

1. Open Jira settings, then System. Under Automation, choose Global automation.
2. Open the Usage tab and switch to the upcoming usage model. That is the steps view.
3. Read the two cards: automation steps this month, split by app, and Rovo credits used by automation. Both are estimates.
4. Under high usage flows, sort by automation steps, highest first. The flow at the top is where to start.

Watch out. The current usage model counts only runs that did something. On it, the same flow in the same month showed four runs, which is why it never looked like a problem. Switch to the upcoming model to see steps.

To see what one run spent, open the flow, then its audit log, and expand a run. A story edit fired the trigger, then three branches ran and found nothing to do: four steps for an edit the flow never needed to see.

Read the flow

Watch this from 4:16

Read a flow from the top, one step at a time, and ask what each part lets in.

The scope is under the menu at the top right of the flow, then Settings.

A tighter trigger

Watch this from 5:53

1. Select the trigger. The panel on the right shows what it listens to: every update.
2. Click the delete icon on the trigger. The list of triggers opens.
3. Search for field value changed and select it.
4. In the fields to watch, type priority and select it, then type due date and select that too.
5. Leave change type on any changes to the field value. That covers a value being added, removed or changed.
6. Under For, choose edit work item. Creating a work item, or moving it through the workflow, no longer starts the flow.
7. Click next. The trigger card reads: value changes for priority, due date.

Rule of thumb. Pick the narrowest trigger that still catches the change you care about. For scheduled flows, the same idea: put the JQL in the trigger, run hourly instead of every five minutes, and include only work items that changed since the last run.

A JQL condition first

Watch this from 7:34

1. Click the plus just below the trigger card.
2. Choose condition, then JQL condition.
3. Enter the query for the work items this flow is for. On the demo site, open epics only: issuetype = Epic AND statusCategory != Done
4. Click validate query. Jira confirms the query works and shows how many work items match.
5. Click next to keep it.

One JQL condition can check type, status and anything else JQL knows, in a single step.

The right scope

Watch this from 8:40

1. Open the menu at the top right of the flow, then Settings.
2. Open the scope list and choose single space.
3. Choose the space: type its name and pick it. On the demo site, Customer onboarding.

An edit in any other space now never reaches the flow. Atlassian's own advice is to avoid global scope wherever you can.

Fewer branches

Watch this from 9:30

1. Zoom out on the canvas until all three branches fit.
2. Open the edit action in the first branch. It sets the priority.
3. Open choose fields to set and add due date.
4. Open the due date's menu, choose copy, then pick trigger work item: the epic that changed.
5. Click next. The one action now copies both fields.
6. Point at the second branch and click its delete icon.
7. Delete the third branch, the comment, the same way. The change already shows in each child's history.

Rule of thumb. When several actions loop over the same work items, put them in one branch. When one action can set several fields, use one action.

Save and measure

Watch this from 10:50

1. Click save. The fixed flow is live.
2. Test it: open an epic in the space the flow is scoped to and change its priority.
3. Back in Global automation, open the flow, then its audit log, and open the new run.
4. Expand each step: the trigger, the condition, the branch and the edit inside it.

Then the same twelve edits were replayed on the demo site. Before the fix they cost 84 steps; after it, 18. The epic edits still did their job. The rest stopped at the condition or never started the flow at all.

Make it a habit. Run the same check on your top five flows every month.