Jira Automation Examples: 8 Rules and Their Cost in Steps

The team lead adds one more rule: “comment when a ticket reaches Done”. It works. Three weeks later the site has used half its automation allowance, and that rule is the biggest line. It fires on every status change and stops at its condition 250 times a month.

From 3 December 2026 Atlassian bills automation by the step. We built three rules on our Jira Cloud site on 5 November 2026 and read their cost from the audit log. Below are eight rules to copy, each with its price in steps.

The allowance and the price

Atlassian’s rules, from its page on how usage is calculated: “An automation step is a single executed part of an automation flow, including triggers, conditions, actions, branches, and loops.” Allowances are pooled per organization and refresh monthly. “On December 3, 2026, extra usage billing takes effect.”

What counts, in Atlassian’s words:

• A trigger is one step, and “Conditions set inside the trigger, such as work item transitioned to Done, are part of that one step and don’t add steps.”
• “A condition that evaluates to false still counts as one step when it runs.”
• A branch is one step “plus the steps in the path that runs”. A loop over three sub-tasks with one action each “counts as four steps total”.
• Free: “Log action, Create variable, Create lookup table, Re-fetch work item data, and Lookup work items”. Use Rovo spends Rovo credits instead; “Use Cursor and Use GitHub Copilot, count as automation steps.”

Three rules we built, and what the audit log said

All three ran on test work items in one space, limited to the label automation-test, and were switched off after the test.

Two things the log showed:

• Inside the trigger is cheaper. B did the same work as A with one step less. Across a month the difference grows with every transition that does not match, as the chart below shows.
• The false conditions were not billed on our site. For the work item without the test label, A and C stopped at their condition with status “No actions performed”, and the log marked them “Non-billable automation steps”. Atlassian’s page says such a condition “still counts as one step”. We saw this on 5 November, before extra usage billing starts, so we price the recipes below by the documentation, not by the log. Check your own audit log after 3 December.

Eight rules to copy, priced in steps

“Steps a run” follows Atlassian’s counting rules. “A month” assumes a 10-person team that creates 200 work items a month (60 bugs, 20 Highest), moves 150 to Done out of 400 transitions, opens 80 pull requests and works 22 days, and charges 2 steps for every run that stops at its condition.

What the arithmetic says:

• On Jira Free, automation is a few dozen runs a month. 150 steps is 75 runs of a two-step rule. Recipe 2 alone would use three times that.
• On Standard with 10 users, 4,000 steps cover all five efficient recipes (1,384) with room left. Rule 1 written the slow way would use almost a quarter of it by itself.
• Event triggers beat schedules that poll. Recipe 5 costs 44 steps a month because Lookup work items is free; an hourly “anything new?” rule costs 730 even when it finds nothing.

Smart values, and what they printed

Smart values are placeholders that Jira fills in when the rule runs. This is what our three rules printed on test work item PAY-31 at 20:05 on Thursday 5 November 2026:

The last row is the trap: the time came out in UTC, an hour behind the Central European time on the screen. A comment that tells customers “created at 19:05” is wrong for everyone not on UTC. Test any time you print in a comment on a test work item before the rule goes live.

Two more things we saw in the builder: rules are now called flows, a flow holds up to 65 steps (“1/65 added”), and the comment action has “Prevent duplicates by only adding this comment once to a particular work item” switched on by default, so a rule that should comment on every run needs it turned off.

Before you switch a rule on

1. Scope it. Limit it to the spaces it is for, and test on a label like ours first.
2. Put the status in the trigger, not in a condition after it, whenever the trigger offers it.
3. Prefer events to schedules, and use Lookup work items (free) instead of a branch where a list is enough.
4. Read the audit log after the first runs. It shows the steps of every run and every failure.
5. Check Usage once a month: Jira Settings, System, Global automation, Usage.

Rules our apps make easier

Several of these rules are better with a field to test or a board to watch. Team Checklist adds JQL fields such as teamChecklistOpen and teamChecklistComplete, usable in automation conditions and JQL lookups, and its settings page has three copy-ready automation rules: a progress comment on every transition, move to Done when the checklist is complete, and a daily email about overdue items. Our Jira checklist guide tests both the native action items and the app.

Recipe 3 sets due dates; Deadline Tracker then shows every work item in columns from Overdue to two weeks out, and our Jira deadlines guide explains what Jira itself counts as overdue. Both apps are free for up to 10 users.

For reports sent on a schedule, automated Jira reports compares filter subscriptions, automation digests and Atlassian Analytics, with what each costs in steps. Rules that move work through statuses depend on the workflow behind them: our Jira workflow guide shows why a rule should set the Resolution when it moves work to Done.

Sources

• Our Jira Cloud site, 5 November 2026: three flows in the flow builder and the automation REST API, test work items PAY-31 and PAY-32, the audit log, the comments the flows wrote.
• Atlassian Support: How is your automation usage calculated (allowances, what counts as a step, extra usage price, where to see usage).