Blog · 24 September 2026

Automation for Jira vs ScriptRunner: which one should run the job

Automation for Jira vs ScriptRunner is mostly a question of who will maintain the job. Jira Automation is built into every Jira Cloud plan, is configured in a form, and is metered in steps against an allowance your whole organisation shares. ScriptRunner for Jira Cloud is a paid Marketplace app from Adaptavist that runs Groovy scripts, and it reaches the places Automation cannot. If a project admin should own the rule and the logic fits in triggers, conditions and actions, use Automation. If the job needs real code, or you already use ScriptRunner's workflow extensions and listeners, use ScriptRunner. This page compares the two as of September 2026: cost, scheduling, failure handling, and who should own what.

The short verdict #

• Most rules belong in Automation. It is already paid for, the rule is readable by anyone with project admin rights, and the step allowance is generous for ordinary work.
• Logic belongs in ScriptRunner. Loops over external data, calculations a smart value cannot express, workflow validators and scripted fields are its home ground.
• Scheduled jobs sit in between, and both tools have a catch there. Automation's schedule draws on a shared pool that can run dry. ScriptRunner's schedule fires at most hourly, with no promise about the minute.
• If the scheduled job only creates the same tickets on a calendar, neither tool is the obvious fit, and a dedicated recurring app is worth a look. More on that below.

How each one is billed #

The two are paid for in completely different ways, which is why a like-for-like price table is misleading.

Jira Automation has no price of its own. Atlassian's usage documentation, read in September 2026, says 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 Jira plan comes with a monthly allowance, and the allowances are pooled across every Atlassian app in the organisation.

Above the allowance, Atlassian states that extra usage is billed at $0.50 per 1,000 additional steps, and that "On December 3, 2026, extra usage billing takes effect." With extra usage switched off, the documentation is blunt: "your automation flows will stop running until usage resets on your usage billing date." Our Jira Automation pricing article walks through what a single rule spends.

ScriptRunner for Jira Cloud is a Marketplace app billed at your Jira user tier. Its Atlassian Marketplace pricing, read in September 2026, lists these annual cloud prices:

So the honest comparison is this. Automation costs nothing extra until your organisation's flows outgrow the pool. ScriptRunner costs a fixed licence and never meters a run. A site with a few busy JQL sweeps may find the licence cheaper than the overage. A site with a dozen quiet rules will never pay Atlassian anything beyond the plan.

What each one does well #

Jira Automation #

Automation is a rule builder: a trigger, optional conditions and branches, then actions. Its strengths are reach and readability.

• It reacts to almost any Jira event, and it can act across Confluence, Jira Service Management and connected tools such as Slack.
• Smart values cover most of the text and date manipulation a ticket needs.
• A project admin can build and change a project-scoped rule without a site admin.
• One rule can cover several projects, which keeps a site-wide policy in one place.

ScriptRunner for Jira Cloud #

ScriptRunner is a scripting platform. Adaptavist's documentation lists, among other features, Script Listeners, Scripted Fields, Behaviours, workflow rules, a Script Console and Enhanced Search JQL functions. Its strengths are depth and control.

• A script can do anything the Jira REST API allows, in whatever order the logic needs.
• Workflow validators and conditions written in Jira expressions go further than Automation's options.
• Scripted fields and Enhanced Search give you calculated data and JQL functions Jira does not ship.
• The cost of that depth is that every job is code. Someone who reads Groovy has to own it, review it and keep it working.

Scheduling: where the two differ most #

Scheduled work is where teams most often weigh one against the other, so it deserves its own comparison.

Atlassian's trigger documentation describes Automation's scheduled trigger like this:

You can run the flow at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules.

It can also run the actions over the results of a JQL query. The same page adds that "Scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically."

ScriptRunner's Scheduled Jobs documentation lists "Create a work item once per month" as its first example use, and sets two limits worth knowing:

The minimum interval between code executions is 1 hour.

It also says the execution time within the hour "cannot be guaranteed", with an hourly job running at 01:02, then 02:24, then 03:00.

Neither failure mode announces itself. An Automation rule that disabled itself or ran out of steps creates nothing and raises nothing in the project. A ScriptRunner job that throws leaves its trace in a log only an administrator opens. If a missing ticket matters, somebody has to be reading those places.

Who should use Jira Automation #

• Your rules react to events such as a transition, a comment or a field change, and most of them run inside one project.
• Project admins should own their own rules without asking a site admin for every change.
• Your step usage sits well inside the allowance, which is true for most small and medium sites with ordinary rules.
• You need a cron schedule that ScriptRunner's day-and-hour dialog cannot express.

Who should use ScriptRunner #

• You need logic, not configuration. Reading an external system, building a ticket per member of a group, or deciding from a calculation whether to act at all.
• You already rely on its workflow extensions, listeners or Enhanced Search. Then the scheduled jobs come free with a licence you are paying anyway.
• Your organisation's Automation pool is under pressure and a handful of heavy JQL sweeps are the reason. Moving those to a script stops them spending steps.
• You are on Server or Data Center. ScriptRunner has editions there too, and the comparison changes.

Recurring tickets: the case neither tool was built for #

A large share of scheduled rules in both tools do one thing: create the same ticket every week, month or quarter. The weekly backup check, the monthly access review, the quarterly report. Both tools can do it, and both make it harder than it needs to be. In Automation the rule spends steps and can switch itself off after repeated failures. In ScriptRunner every field on the ticket is a line of Groovy.

That is the job Recurring Work Items for Jira is built for. A rule is a schedule plus an issue template, set in a form inside one enrolled project. Titles and dates roll forward through a documented token vocabulary. Every occurrence, whether created, skipped or failed, is written to the rule's History with its reason, and it never runs an Automation rule, so it spends none of your steps. It is free for up to 10 users, then from $82.50 a year for 11 to 15 users. It creates issues from a template and nothing else, so it replaces neither tool for anything beyond that.

If you are already weighing that route, ScriptRunner alternative covers moving a Scheduled Job across, and Jira recurring tasks compares Automation, cloning and apps for the same job.

How to decide in practice #

1. List your scheduled and event rules in both tools, with what each one creates or changes.
2. Mark each one as configuration or logic. Configuration fits a form. Logic that needs loops, external calls or arithmetic fits a script.
3. Check your organisation's step usage in Atlassian Administration under Insights, then Platform usage. That tells you whether the pool is a real constraint.
4. Put each rule where its owner can maintain it. A rule only one scripter understands is a risk even when it works.
5. Pull out the pure recurring-ticket rules and decide whether they belong in either tool at all.

Jira Automation allowances and behaviour were read from Atlassian's support documentation, and ScriptRunner prices and features from its Atlassian Marketplace pricing and Adaptavist's documentation, in September 2026. Both can change without notice. Jira Automation is a product of Atlassian and ScriptRunner a product of Adaptavist; this page is not affiliated with or endorsed by either.