One-page brief · Vikash Kumar · October 2026

Wasted steps in Jira automation

From 3 December, every automation step has a price. Admins can already see which flows use the most steps. They can't see how many of those steps did nothing, why, or what to change.

What I tested

I built a Jira test site with 9 automation flows, each built to show one cost pattern: a broad trigger, a narrow trigger, a branch over sub-tasks, a daily scheduled search, a failing web request, and a flow that edits before it checks. For every run, I wrote down a step prediction before the Usage tab reported it.

56 of 57
steps predicted correctly, across 17 runs
21%
of all steps went to runs that did nothing or failed
40%
of one broad flow's steps did nothing

What I found

  1. Waste is easy to miss. A flow that starts on every update and then checks a label used 15 steps over 6 runs. 3 runs stopped at the check and did nothing, using 6 of the 15 steps. The Usage tab shows "15 steps" and nothing more.
  2. A badly ordered flow looks healthy. A flow that edits a work item before checking whether it should stopped at the check, used 3 steps, changed the item anyway, and its run was marked Success. Nothing tells the admin the flow is built in a costly way.
  3. Per-item cost is hard to trace. Branches and scheduled searches cost one step per work item. The audit log shows each action as one line, so an admin can't see where a flow's cost comes from. A daily search over 500 work items would use about 15,000 steps a month on its own.

Also seen: the Usage tab took about two hours to reflect new runs, and a web request counts as 2 steps, whether it succeeds or fails.

What admins can see today

Question an admin asksUsage tab today
Which flows use the most steps?Yes, ranked by flow
How many of those steps did nothing?No
Why is this flow expensive?No
What should I change, and what would it save?No

One idea for the Usage tab

Add one column and a few plain-language flags to the high usage flows table. The flags come from the flow's structure and its run outcomes, both of which Atlassian already has.

What I'm building

Stepmeter is a small open-source tool that does this outside the product today: it reads each flow's structure and run results, shows the wasted steps per flow, explains the cause, and suggests a fix with its saving. See the demo report for what it shows.

A working prototype now builds this report automatically from a live site: it reads every flow through the API and counts runs from each work item's change history. On the test site it matched the Usage tab's run count for all 7 flows that react to events, and accounted for 89 of 97 steps. The gap was one manual run of a scheduled flow, which history can't see.

Next, I want it to work from a rules file the admin exports and opens in their own browser, so no access to their site is shared. I haven't confirmed yet that the export contains everything it needs.

Where I'd value your view

The method, every decision and the raw results are in the build journal and decision log. Not affiliated with Atlassian.