A practical way to audit Jira Automation rules before step-based billing

Question

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.

Hinata - StepWise · Answer

Thank you for the detailed feedback. The distinction between organization usage, runtime evidence, static JSON analysis, and manual semantic review is the right one.

I turned that into a short six-step checklist with a worked structural example:

https://stepwise-jira-automation.pages.dev/checklist

The checklist keeps configured components separate from executed steps. In particular, it treats NO_MATCH triggers, early condition exits, and branch or loop cardinality as runtime questions rather than claiming an exact monthly saving from JSON alone.

I also validated the parser against four complete Jira Automation exports published in Atlassian Support articles. All four parsed without unknown components. The next validation gap is a real customer export paired with execution-frequency or run-log evidence.

If anyone is willing to test it, please use a non-sensitive export in your own browser. No Jira connection or server upload is required. I would be especially interested in cases with broad scheduled queries or branch fan-out.

Carlos Garcia Navarro · Answer

HI @Hinata - StepWise ,

Welcome to the Community! The practical answer is: use all three ( manually, through scripts, or through the Administration usage view). Each covers a different part of the audit, and none is sufficient alone.

Atlassian Administration shows organization-level consumption against the pooled allowance under Insights → Platform usage. It is useful for budget monitoring and trend detection, but it does not explain which structural changes should be made to individual rules. Usage calculation and administration view

Automation audit logs provide the best runtime evidence. They show each execution, its status, and the steps attempted. Logs are retained for 90 days, so admins can sample actual frequency, early exits, NO_MATCH triggers, failures, and branch behavior. Automation run logs

Export-analysis scripts or tools are useful for auditing many rules consistently—counting components, finding duplicated conditions, identifying broad scheduled queries, and flagging branches. Jira can export all global and project-scoped rules to JSON. Importing and exporting rules

Manual review remains necessary to decide whether two conditions are actually equivalent and whether moving them into JQL changes the rule’s meaning.

There does not appear to be authoritative public data showing what proportion of Jira admins use each method. The strongest process is therefore a hybrid:

Use Platform usage to establish whether usage is a material problem.

Use execution counts or audit logs to identify frequently running rules.

Analyze exported JSON to rank possible inefficiencies.

Confirm actual behavior in the audit log.

Have an admin validate semantics before changing the rule.

Compare usage and results after the change.

For your example, “five configured components” is correct, but it is not necessarily five consumed steps per scheduled invocation:

If the trigger returns NO_MATCH, only the executed trigger may count.

If the first condition fails, later components do not execute.

If both conditions pass, the branch executes.

Actions inside the branch can execute repeatedly according to fan-out.

Moving project = OPS AND issuetype = Bug into the scheduled query is a sensible finding to flag. It should be presented as a potential optimization, not a calculated saving. It may reduce downstream condition executions, but only runtime data can establish the monthly reduction.

Your most valuable audit findings would likely be:

High-frequency rules with repeated downstream filtering.

Scheduled triggers frequently returning NO_MATCH.

Conditions that can safely be pushed into trigger JQL.

Expensive branch or loop fan-out.

Duplicate or unreachable conditions.

Rules producing NO_ACTIONS_PERFORMED, ABORTED, or repeated errors.

Multiple rules reacting to the same event and performing overlapping work.

In short: the Administration view tells admins how much they are using; logs explain what actually ran; JSON analysis identifies where to investigate; manual review determines what is safe to change.

Jovânio Junior · Answer

Hi Hinata, welcome to the Atlassian Community!

I think your approach makes sense, especially with the new step-based usage model.

The main thing I’d watch is branch/loop fan-out, because that’s where static analysis can quickly diverge from actual runtime consumption.

I also agree that pushing filters earlier into the trigger/query is probably one of the easiest ways to reduce unnecessary executions.

A JSON checklist would definitely be useful, especially for admins reviewing large rule sets.