Blog · 16 September 2026

Jira Automation pricing: what it costs and what a rule spends

There is no separate Jira Automation price list. Automation comes with your Jira subscription, and what you pay for is usage: Atlassian meters automation in steps, gives each plan a monthly step allowance, and charges for anything above it. As of September 2026 the allowance is 150 steps per subscription on Free, 400 steps per user on Standard, 750 on Premium and 1,000 on Enterprise, pooled across your organisation's Atlassian apps, with extra usage billed at $0.50 per 1,000 additional steps. The practical question is therefore not "what does Jira Automation cost" but "how much of my allowance does this rule spend, and what happens when the pool runs dry" — and the answer is different for a scheduled rule that creates one work item than for one that loops over a JQL result.

What "Jira Automation pricing" actually means

Most pricing guides you will find answer a different question: what the Jira plans cost. Automation is not one of those line items. It is included, then metered, and quite a few pages still describe an older model that counted whole rule runs rather than steps.

The current model, from Atlassian's own usage documentation (checked September 2026), is this: "Automation usage is measured in steps. An automation step is a single executed part of an automation flow, including triggers, conditions, actions, branches, and loops." Each of those components counts as one step every time it runs, and steps are counted for flows that finish as success, no-actions-performed, some-errors, aborted and no-match alike — so a flow that fires and decides to do nothing has still spent its trigger and its condition.

Two consequences matter before you budget anything:

• The allowance is pooled at the organisation level. Atlassian states that "your organization's total step allowance is the sum of all automation steps across your apps". A noisy Confluence flow and a busy Jira Service Management flow draw on the same pool as your quiet weekly maintenance ticket.
• Two flows that cost the same to write can cost very differently to run. A flow is billed by how many components execute, not by how many rules you have switched on.

What each Jira plan allows

As of September 2026, Atlassian's documented monthly step allowances are:

On a per-user plan the pool scales with your licence count, so a ten-seat Standard site has 4,000 steps a month to spend across everything automated in the organisation. That sounds generous until a single scheduled flow with a JQL query starts iterating.

What happens when the allowance runs out

Atlassian documents two outcomes, and which one you get depends on a setting you may not have looked at:

• Extra usage enabled: "Metered features continue to run without interruption. Extra usage is charged on your next invoice at the end of the billing period" — at $0.50 per 1,000 additional steps.
• Extra usage disabled: "If extra usage is disabled and you reach 100% of your total steps allowance, your automation flows will stop running until usage resets."

The second is the one to plan for, because it is silent in exactly the way a recurring ticket is silent. Nothing errors. The Monday maintenance ticket simply does not appear, and the first person to notice is whoever goes looking for it a week later. If your recurring work is compliance work — access reviews, backup restore tests, certificate renewals — a missing cycle is the cycle the auditor asks about.

What a recurring rule actually spends

Take the simplest useful case: a scheduled flow that creates one work item on a fixed schedule. The trigger runs, the create action runs. That is two steps per firing, plus one more for every condition, branch or loop you add. A daily rule therefore spends roughly 60–90 steps a month; a weekly one, under 10.

By that arithmetic, recurring creation is cheap, and for a handful of rules the allowance will never be your problem. The cost shows up in two other places:

1. Scheduled flows that work on a JQL result. Atlassian's scheduled trigger lets you "enter a JQL query", after which "actions in this flow will execute on the work items included in the query" — and branches and loops are on the list of components that count as a step each time they run. A weekly flow that sweeps two hundred work items is a different animal from one that creates a ticket, and it draws from the same pool your recurring tickets need.
2. Everything else in the organisation. Your recurring rules do not compete with a budget of their own. They compete with every other flow across every Atlassian app you run, and they lose quietly, because they are the ones nobody is watching.

There is a second behaviour worth knowing before you rely on a schedule: Atlassian documents that "scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically" (checked September 2026). That is sensible engineering, and it means a schedule can switch itself off in the background. Whether anyone finds out depends on whether somebody is reading audit logs.

Who should stay with Jira Automation

Plainly: most teams, for most recurring work.

• You have a handful of recurring rules and plenty of allowance. You are already paying for Automation. Adding an app to save a few hundred steps a month is not a saving.
• You need a cron expression. Automation's scheduled trigger runs "at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules". If your schedule genuinely needs cron syntax, that is a real reason to stay.
• Your rule does more than create something. Transitions, conditional branches, JQL sweeps, cross-product actions, Slack messages, smart-value arithmetic — that is what Automation is for, and no narrow scheduling app replaces it.
• You want one rule covering many projects. A multi-project Automation rule is one rule; a project-scoped app means one rule per project.

When a scheduling app is the better fit

The case for moving recurring creation out of Automation is not usually money. It is that recurring work has different failure modes from event-driven work, and a metered shared pool is a bad place to keep something that has to appear on the same date every month.

Marketplace scheduling apps exist for exactly this, most of them licensed per user through Atlassian. Recurring Work Items for Jira is one of them, and it is the one we build: rules live in a single Jira project, run on the app's own schedule rather than your automation allowance, and each one keeps a run history of what it created and when.

What that buys, concretely:

• Schedules that understand the working week. Daily, weekly, monthly-by-date and monthly-by-ordinal ("the last Friday"), with a per-project working-day calendar and a per-rule choice of what to do when an occurrence lands on a non-working day: run anyway, move to the next working day, move to the previous one, or skip the cycle. See the rule reference.
• Titles that change with the date. Tokens render the cycle into the summary and description, so "Access review — September 2026" is the rule, not a monthly edit. The token reference has the vocabulary.
• A record of every cycle. Run history says what each firing produced, and the next run is predicted with the same logic that will execute it.
• Guards against pile-up. A rule can be told to create nothing until the previous issue is closed, and can create up to ten subtasks under each issue it makes.
• Pricing that does not move with usage. Free for up to ten users, then $5.50 per user per year — a fixed number, not a meter.

What it does not do, so that nobody buys it twice: no cron expressions, no cross-project rules, and nothing event-driven. It creates scheduled work items in one project, and that is the whole of it. If you need cron or a multi-project rule, stay with Automation or look at a Marketplace app that offers them.

A comparison, honestly

Before you change anything, measure

The cheapest move is not buying anything. Open your organisation's automation usage, find out whether extra usage is enabled, and look at which flows are actually spending the pool — it is very rarely the recurring ones, and if a JQL-driven sweep is the culprit then moving your maintenance tickets elsewhere solves nothing.

If the numbers say recurring work is worth taking off the meter, our walkthrough of the three ways to do recurring tasks in Jira compares cloning, Automation and an app side by side, and the install guide takes about five minutes.

Every figure attributed to Atlassian above was read from Atlassian's own automation usage and trigger documentation in September 2026. Allowances and prices change; check them against the current pages before you budget on them.