Disclosure: I am building a small browser-based audit tool for Jira Automation exports. The example below is the manual method I used to validate the tool's estimates.
With the new usage model, a step is a single executed trigger, condition, action, branch, or loop. That means a rule can consume steps even when an early condition stops the rest of the flow, and a trigger that returns NO_MATCH can still count.
Consider this simplified rule:
1. Scheduled trigger
2. JQL condition: project = OPS
3. Issue type condition: Bug
4. Branch over related issues
5. Edit issue action
Its static structure contains five billable components on the represented path. This is not a monthly cost estimate: schedule frequency, matched issues, branch fan-out, and actual execution status still matter.
A useful audit sequence is:
- Start with rules that run frequently.
- Count triggers, conditions, actions, branches, and loops.
- Flag broad scheduled queries followed by narrow conditions.
- Check for duplicate or overlapping conditions.
- Treat branch and loop findings as review items because fan-out is runtime-dependent.
- Only rewrite JSON when semantic equivalence is clear.
For example, if the scheduled query can safely include project = OPS AND issuetype = Bug, the two downstream conditions may become unnecessary. The static path changes from five configured components to three, but the real monthly reduction remains an estimate until execution frequency and branch behavior are known.
I am interested in whether Jira admins are currently auditing this manually, through scripts, or through the Administration usage view. I will add a worked JSON checklist in a follow-up if it would be useful.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.