I'm part of the team behind Automation Map for Jira (MOY Apps). This walkthrough shows how to optimize your rules ahead of the new pricing; the first section, and every optimization pattern covered here, can be applied directly in native Jira.
From 3 December 2026 Jira Automation is billed by the step: $0.50 per 1,000 steps above the allowance pooled across your organisation (how automation usage is calculated). @Sami Shaik's article Automation steps start billing on 3 December explains the allowance and the meter. This one shows how to find, rule by rule, which steps can go and what each fix is worth, on a demo site of 1,088 rules we built for these screenshots.
Before the app: three facts, and what Jira shows you today
- Every component that runs is a step: the trigger, each condition, each action, each branch, and each turn of a loop.
- A trigger that fires and matches nothing still counts: NO_MATCH is one of the five charged outcomes in Atlassian's doc.
- A run that stops at a condition still pays for everything before it.
Since September the redesigned Automation → Usage tab (beta, release note) estimates the steps and runs of each rule and sorts the top 100 by steps. Start there: it tells you which rules spend the steps. What it does not tell you is which of a rule's steps can go, and what removing them is worth a month. That is what the rest of this article does.
Step 1. Load your rules once, by hand (optional)
Export your rules from Jira (Automation → the ••• menu → Export rules) and upload the file in Jira settings → Apps → Automation Map → Data. The app asks for no API token and changes nothing in Jira; a site of a thousand rules is mapped in about a minute. This is enough for the map, the cost of one run of every rule and its findings, on every edition.
Step 2 (Advanced). Let a daily job keep it current and bring in the real runs
Uploading an export by hand is fine once. To audit every month, let a small sender of your own push the rules every night. The token stays with you: the job reads the rules with your own API token and pushes them with a key the app issues, which is all the app ever sees. Pick whatever you already run:
- Inside Jira, nothing to host: a ScriptRunner Scheduled Job, or a JMWE Scheduled action. Paste the script from the app's setup guide, set the variables, run it daily.
- On your own side: the Docker image (GitHub Actions, GitLab CI, a Kubernetes CronJob or plain cron), or the same sender as a Python, Node, bash or PowerShell script.
The sender also reads this month's usage figures and the audit log (beta): the steps and runs of each rule, and the runs that failed. That is what turns "what one run costs" into "what this rule costs this month, and what the fixes would have saved" in the steps below.
Pushing, the month figures and the site-wide audit are on the Advanced edition. The setup guide is in Data → Push from your side → Set up; it makes the key and fills it into the snippet for the tool you pick.
Rules and usage data are pushed directly into the app’s secure storage via an app-generated ingestion key. No personal user data or Jira issue content is ever read or transmitted — strictly automation rule definitions and audit statistics.
Step 3. Open the map and read the tiles
Open Apps → Automation Map and pick a space. The tiles above the map are the space against the whole site: rules, live chains, conflicts, steps per run and could save, and with a sender on Advanced, steps this month, could save this month, runs this month and failed runs.
The map of a support space: 66,281 steps this month, 23,170 of them the fixes would remove. One rule is selected and the two rules it sets off are shown.
Step 4 (Advanced). Rank the rules by what the fixes would save this month
Go to Audit → Usage and sort by Most to save this month first. Every rule shows its steps per run, its steps this month with the runs behind them, and what could be cheaper and by how much. This is the list Jira's Usage tab cannot give you: ranked by what you can remove, not by what is spent.
The support space ranked by what the fixes would save this month: a rule that only logs (6,762), a rule with five fixes (4,900), a constant edit a post-function could do (2,702), a log action on every run (2,600).
Work from the top. On the whole demo site the top ten are all "Log every update" rules: 2 steps a run, almost 6,000 runs a month each, 100% removable. It is rarely the rules that look complicated. Export the list to CSV for the clean-up ticket.
Step 5. Open a rule: what one run costs, and what the fixes take off
Click a rule. The Overview tab shows its purpose and the cost of a run: a bar of its steps, the steps if all of it runs, and how many are left after the fixes, with each fix on its own line and the steps it saves.
"Tag new requests by product": 9 steps if all of it runs, 2 after the fixes. 700 runs and 6,300 steps this month.
The Findings tab says what each fix is, in the words you will use in the editor, and the steps it saves per run (or what it is worth this month on Advanced). It also names the rules racing with this one on the same trigger.
Findings: one JQL condition instead of three, two edits merged into one, a log action and a re-fetch removed, a condition moved first. Each with its saving per month.
Step 6 (Advanced). Diagnosis and Activity: the fixes times the real runs, and the runs that fail
Diagnosis does the multiplication for you: the steps the fixes would save per run, times the runs this rule had this month.
7 steps a run, times the 700 runs it had this month: 4,900 steps from one rule.
Activity shows the runs behind it: how many, how many did nothing, how many failed and with which error, and the hours the rule is busiest. A rule that fails a lot is paying steps for nothing too, and Diagnosis names the rules that wait on it.
Activity of another rule: 2,301 runs in 30 days, 196 did nothing, 48 failed on the outgoing e-mail action.
Step 7. Ask Rovo what to change
Every finding has Ask Rovo what to change, and the card has a Rovo menu. The app's agent, Automation Expert, answers from the same map, on every edition; with the month figures in, it answers with them. Two questions that work well:
- "Look at the rule … and its cost findings, and tell me exactly what to change in the editor to make each run cheaper without changing what it does."
- "Use the Automation Map: which rules on this site failed the most in the last 30 days, and which spend the most steps this month?"
Rovo names the step to delete, why it is safe, and what it saves this month.
Rovo across the whole site: the rules that failed most, with the last error, and the rules that spent the most steps.
Power user tip: Automation Map also exposes native Rovo / MCP tools, so you can build your own custom Rovo agents or integrate automation health checks into your existing AI workflows.
Step 8. Make the change in Jira, then check
Click Edit in Jira on the card, make the change in the rule editor, and save. Safety first: the app never touches or mutates your live rules. You retain full control over every change in the native Jira Automation editor. With a sender, the next night's push shows the new cost of a run and, over the following days, the month figures falling; without one, upload a fresh export.
Re-do the ranking once a month. Rules drift: someone widens a JQL or adds a branch, and the shape you fixed in October is a different one by February. A nightly sender is what catches that without anyone remembering to.
What the app checks
Fifteen patterns, each with the step it names and the saving: log actions on every run, rules that only log, re-fetches after nothing changed, a row of conditions one JQL could replace, filters the trigger could apply for free, conditions paid for too late, consecutive edits of one work item, schedules that rescan every item or run hourly, branches used as a yes/no check, variables used once, site-wide rules that only ever act in a few spaces, and work Jira could do without automation (a post-function or a field default). Branches that multiply the cost are counted on their own.
Standard or Advanced
- Both: the map, the cost of one run and the findings on every rule, and the Rovo agent. Rules come in from an export you upload.
- Advanced adds the audit: a nightly sender (ScriptRunner, JMWE, Docker or a script) instead of uploads, this month's steps and runs from Jira's Usage tab, the site-wide list ranked by what the fixes would save with a CSV, Diagnosis and Activity on every rule (beta), and AI-written rule descriptions.
If you are preparing for 3 December, Advanced is the edition that turns the per-run findings into a monthly number you can put in front of whoever pays the bill.
Automation Map for Jira (Rule Dependencies & Cost Savings) on the Atlassian Marketplace
What is at the top of your list? I am curious whether "log every update" wins on real sites the way it does on the demo.
