Audit your Jira automation before the December 3 step meter starts

On December 3, 2026, Atlassian's usage-based pricing allowances and meter billing start, and Jira automation will be billed by execution steps rather than completed rule runs. The unit you now need to count is the step: each trigger, condition, action, branch, or loop is one step, and each repeated loop pass adds more. That shifts the audit from rule inventory to step burn.

Steps are the budget unit

The meter watches the components inside the run. A simple rule with a trigger, a condition, and an action is easy to estimate. A rule with a branch and a loop is harder, because the loop is where the bill hides. If a rule fires every fifteen minutes and usually matches nothing, it can execute about 2,880 times in a month and use roughly 5,700 steps. That rule can look harmless in the list and expensive on the invoice.

The count follows components, not rule inventory. A short rule can be expensive if it loops, and a long rule can be cheap if it rarely fires. The audit needs a component view, including run history that shows whether those components produced anything useful.

Run the audit before the meter starts

The checklist below is the pre-metering audit. The order matters because the step estimate comes before the choice, and the choice should be deliberate before the first invoice.

• Read the usage dashboard, then note the current meter and the applicable allowance for your tier.
• List every active automation rule and its trigger type.
• Count triggers, conditions, actions, branches, and loops in each rule.
• Flag any rule with a loop and note the maximum pass count.
• Mark scheduled rules that usually match nothing.
• Review run history for failed and empty executions.
• Compare your estimated monthly steps against your tier allowance.
• Set the default extra-usage option deliberately before the meter starts.
• Choose slim flows, buy extra usage, or accept overage.

Billing follows the meter, not your intent. The component count is the real budget, since the meter prices parts, not outcomes. Empty runs still consume allowance, including NO_ACTIONS_PERFORMED, SOME_ERRORS, ABORTED, and NO_MATCH. Enterprise customers receive 1,000 automation steps per user per month under the new model. If your estimate sits near that line, the decision is no longer theoretical.

If your tier is not Enterprise, use the applicable allowance as the limit. Keep the comparison on the same cycle as the invoice, so the number you act on is the number that will appear on the invoice.

Choose slim, buy, or accept

Slim flows are the first lever. Remove branches that only exist for edge cases, shorten loops, and replace broad scheduled checks with event-driven triggers where the workflow allows it. You want fewer steps per useful outcome, not fewer rules for their own sake. That is the test for each rule. Event-driven triggers can be cheaper than polling, because they fire only when the workflow has something to do. Polling rules can run all month and produce nothing.

Buying extra usage is the second lever. It is the right move when the workflow is genuinely useful and the step count is stable. It is the wrong move when the workflow is an unreviewed placeholder. Set the default deliberately, because the invoice will follow the default you leave in place.

Accepting overage is the third lever, and it should be a decision, not a surprise. If the step count is high because the automation is doing real work, you may accept a higher bill for a while. When the count is high because a rule is mostly empty, the overage is a signal to cut. Treat this as a software vendor cost audit, not a cleanup project. The output is a number, a default setting, and a written decision. Put it down before the invoice arrives, because the meter will not adjust for your intent. A one-line note is enough.