Blog ·
ScriptRunner alternative for recurring Jira issues: cost and fit
If you are looking for a ScriptRunner alternative because the only thing your ScriptRunner licence still does is create the same Jira ticket every week or month, a dedicated recurring-work app will usually do that job for a fraction of the price and without a Groovy script to maintain. If ScriptRunner also runs your workflow validators, scripted fields, listeners and Enhanced Search, keep it. This page sets out what ScriptRunner for Jira Cloud's Scheduled Jobs do, what the app costs as of September 2026, who should stay, and how to move the recurring half of the work to Recurring Work Items for Jira if that is the part you are paying for.
The short verdict #
- ScriptRunner does many jobs on your site? Stay. A recurring-work app replaces one feature of it, and the rest of what you would lose is the reason people buy it.
- ScriptRunner exists on your site mainly to run a Scheduled Job that creates tickets? That is the case this page is for. You are paying for a scripting platform to do a scheduling task.
- Nobody on the team can read the Groovy any more? A script only its author understands is a maintenance risk even when it works. A form-based rule is easier to hand over.
- Ten users or fewer? Both apps list a $0 tier at that size, so the decision is about maintenance, not money.
What ScriptRunner's Scheduled Jobs do #
ScriptRunner for Jira Cloud, by Adaptavist, is a scripting platform. Scheduled Jobs are one feature among many. Its own documentation, read in September 2026, describes them like this:
Scheduled Jobs allow you to automate the running of scripts at regular intervals saving your administrators time, and reducing the risk of human error.
The first use case the same page lists is "Create a work item once per month", followed by emailing reports, deleting inactive users and changing a work item's status based on its age. Its worked example is close to what most teams want: a task for each consultant at the end of every month, reminding them to file expenses.
How it works, from that documentation:
- You write the code to run, in Groovy, or load a saved script or one of the bundled examples.
- The schedule is chosen in a dialog: certain days of the week, or particular days of the month, such as the last day or the second Tuesday, plus an hour window.
- The job runs as a user you name.
- "The minimum interval between code executions is 1 hour." The documentation also says the exact execution time within the hour "cannot be guaranteed", with an example of an hourly job firing at 01:02, 02:24 and 03:00.
That is a capable, general tool. The cost of that generality is that the recurring ticket is a script, so every field on the ticket, every subtask and every date in its title is code somebody wrote and somebody has to keep working.
What ScriptRunner for Jira Cloud costs #
These are the published cloud prices for ScriptRunner for Jira, read from its Atlassian Marketplace pricing in September 2026, set beside ours. Marketplace apps are billed at your Jira user tier.
| Jira user tier | ScriptRunner for Jira, annual | Recurring Work Items, annual |
|---|---|---|
| Up to 10 | $0 | $0 |
| 15 | $393 | $82.50 |
| 25 | $655 | $137.50 |
| 50 | $1,310 | $275 |
| 100 | $2,620 | $550 |
Our own figures are the ones on our home page: free for up to 10 users, then from $82.50 a year for 11 to 15 users, rising with the tier.
Read that table fairly. The ScriptRunner column buys a scripting platform, of which scheduling is a small part. It is the right comparison only if scheduling is the part you use. If you rely on its workflow extensions, behaviours or Enhanced Search JQL functions, the ScriptRunner price is buying those too, and a recurring-work app replaces none of them.
For the other ways teams schedule work in Jira, including the free route through Jira Automation and what it costs once rules pile up, see Jira Automation pricing.
Where the two approaches differ #
| ScriptRunner Scheduled Job | Recurring Work Items for Jira | |
|---|---|---|
| What you write | A Groovy script | A rule: a schedule plus an issue template, in a form |
| Schedule | Days of the week or of the month, plus an hour window | Daily, weekly, monthly and quarterly rules, with working-day and holiday handling |
| Timing | At most hourly; the time within the hour is not guaranteed | A scheduled trigger every 5 minutes that claims each occurrence exactly once |
| Dynamic titles and dates | Whatever the script builds | A documented token vocabulary |
| Subtasks | Created by the script, if you write that part | An ordered subtask list on the rule |
| When a run fails | The job's logs and execution history | A History row for every occurrence, created, skipped or failed, with its reason |
| Scope | Whatever the script touches, anywhere on the site | One enrolled project; other projects are untouched |
| Hosting | Jira Cloud (Server and Data Center have their own editions) | Jira Cloud only, as a Forge app on Atlassian's infrastructure |
The row that decides most cases is the first. If the people who own the recurring tickets are not the people who can write Groovy, every change to a ticket becomes a request to an administrator. A form puts the change back with the project admin whose team does the work.
Who should stay with ScriptRunner #
- You use it for more than scheduling. Workflow validators, post functions, listeners, behaviours and scripted fields are its core. Our app does none of them.
- Your recurring job does something a template cannot. Creating a ticket for every user in a group, reading an external system first, or deciding whether to create anything from a JQL result: that is logic, and logic belongs in a script.
- You schedule work across many projects from one script. Our model is the opposite choice: a rule lives in one project.
- You are on Jira Server or Data Center. We are Cloud-only.
Who should look at a dedicated recurring app #
- The Scheduled Job creates the same ticket on a calendar, with a fixed summary, assignee and a few subtasks.
- The licence is renewed mainly for that job. The table above is the bill you are carrying for it.
- You need to show why a ticket did not appear. Every occurrence gets a History row with its reason, and the failure codes are published on a troubleshooting page.
- You want working days and holidays handled without writing date arithmetic.
- Project admins, rather than site admins, should own the schedule.
How to move a Scheduled Job, without a gap #
- Read the script once and write down what it creates. Project, issue type, summary pattern, assignee, labels, due date, subtasks, and the schedule. That list is your rule.
- Install the app and enrol one project. Start with the job you would miss most.
- Build the rule in the editor and check the Next runs preview against the dates the script has been hitting. Month ends and holidays are where differences show.
- Map any dates in the summary to tokens so "Expenses for September" keeps rolling forward on its own.
- Run both for one cycle. A duplicate ticket for one month is easy to close. A missing one is harder to explain.
- Disable the Scheduled Job, which keeps the script in ScriptRunner if you ever need it back, and check the rule's History after its next run.
- Only then decide about the licence. If nothing else on the site uses ScriptRunner, that is the saving. If something does, you have simply moved one job to the tool built for it.
If your recurring tickets are really a parent plus a fixed set of steps, Jira subtask template compares the ways to get those steps attached every time. If you are weighing the dedicated scheduling apps against each other, Repeating issues in Jira sets out their prices side by side.
Frequently asked #
Is ScriptRunner free for small teams? Its Marketplace pricing lists $0 for the 10-user tier as of September 2026. Above that it is billed at your Jira user tier, starting at $393 a year for 15 users.
Can a recurring-work app run my Groovy? No. It creates issues from a template on a schedule. If your job runs custom logic, keep that job in ScriptRunner.
Does it use my Jira Automation quota? No. The scheduling is the app's own and it never creates or runs an Automation rule.
What happens to tickets the Scheduled Job already created? They are ordinary Jira issues and stay where they are. Only the schedule moves.
ScriptRunner prices and feature descriptions were read from Adaptavist's documentation and ScriptRunner for Jira's Atlassian Marketplace pricing in September 2026 and can change without notice. Check the listing before budgeting. ScriptRunner is a product of Adaptavist; this page is not affiliated with or endorsed by them.