Blog · 23 September 2026

Repeating issues in Jira: the apps, the prices, and which one fits

If you want repeating issues in Jira, you have three honest options: build a scheduled Jira Automation rule, install a Marketplace app that creates the issue for you, or keep cloning by hand. This page is about the middle one. It sets out what Repeating Issues for Jira by Codedoers does, what it costs today, who should install it, and where Recurring Work Items for Jira is the better fit instead.

The short verdict #

• Ten users or fewer? Both apps are free at that size. Pick on shape, not price.
• You want a recurrence attached to an existing issue, so the issue itself clones, reopens or grows subtasks on a schedule? That is what Repeating Issues for Jira is built around, and it is the better fit.
• You want rules that live in one project, each with a template, a preview, and a run history that says what happened on every occurrence? That is the shape we built for.
• You need Jira Server or Data Center? Repeating Issues for Jira supports them. We are Jira Cloud only, so the decision is already made for you.

What Repeating Issues for Jira does #

Taken from the app's own Atlassian Marketplace listing, checked September 2026:

Automate your work with recurring tasks. Quick and simple issue scheduler in just a few clicks for Jira

The model is worth understanding before you compare anything, because it is genuinely different from a rule-based scheduler. You open an issue, and you attach a recurring action to it. The listing describes scheduling a "clone issue, create sub-task or execution of any workflow on issue, e.g. reopen issue", and says the "recurring action summary, its frequency and next occurrence date are visible on the repeating issue section".

So the issue is the anchor. A weekly server check becomes one issue that clones itself every Monday, or one issue that reopens itself every Monday, depending on which action you pick.

The listed capabilities, in the vendor's own words:

• Schedule clone issue, create sub-task, or execution of any workflow on issue
• Schedule issue create date or due date, and set a relative due date for new issues
• "Variables in action texts, e.g. in summary, description with math operations on dates"
• "Edit custom field values with velocity expressions"
• "Create exceptions for recurring events with non-working days support"
• Manage permissions per project
• Works with Jira Software and Jira Service Management
• "Recurrence rules supports iCalendar RFC"

Two of those deserve a note. Non-working-day support is a real differentiator against Jira Automation, which has no idea what your holidays are. The listing goes further and ties it to service targets: "Non-working days for repeatings also helps you guarantee your SLA in Jira Service Desk." And iCalendar recurrence rules mean the frequency vocabulary is the calendar standard rather than cron, which most people find easier to reason about than a five-field expression. If cron is what you actually want, our Jira cron expression guide covers what it can and cannot say.

The app also lists project automation rules that "set details of the repeating to issue when issue is created", so a project can apply a default recurrence to issues as they arrive rather than making somebody attach one each time.

The current Jira Cloud version at the time of writing is 4.0.0, released 15 September 2026. It works with Jira Cloud, Jira Server and Jira Data Center.

That is an actively maintained app doing a well-defined job. Nothing below is a claim that it does the job badly. The question is fit.

What Repeating Issues for Jira costs #

These are the published Jira Cloud prices for the app, read from Atlassian's Marketplace pricing data in September 2026. Atlassian bills Marketplace apps at your Jira user tier, so the tier you sit in is what you pay for, not your actual headcount.

Two things about that table matter more than the numbers themselves.

The renewal price is half the first-year price. That is an introductory discount, and it runs the normal way round: year one costs more, and the figure you will actually live with is the right-hand column. Budget against the renewal.

It is free up to ten users, and so are we. At that size there is nothing to save by moving in either direction, and anybody telling you otherwise is selling something. Our own price is the one on our home page: free for up to 10 users, then from $82.50 a year for 11 to 15 users, as a flat band per user tier rather than a per-user rate.

Repeating issues in Jira without an app #

Jira's own Automation has a scheduled trigger, it is included in your Jira subscription, and it will create a repeating issue perfectly well. Most teams should try it before installing anything. We wrote up six working rules and where each one breaks in Jira automation examples.

The reason a paid app exists at all is that Automation meters usage in steps, and every part of a rule counts: the trigger, each condition, each branch, each action. A recurring create rule spends at least two steps every single time it fires, and the allowance is pooled across your whole organisation. Jira Automation pricing has the per-plan allowances and what happens when they run out.

The second reason is calendar awareness. Automation's scheduled trigger does not know your holidays or your working week, so a rule that fires on the first of the month will happily create a ticket on a public holiday. Both Repeating Issues for Jira and we handle that; Automation does not.

Where the two apps actually differ #

The row that decides most comparisons is the first one. A recurrence attached to an issue and a rule that creates issues are different mental models, and neither is wrong. If the thing that repeats is best described as "this ticket, again", the issue-anchored model reads more naturally and you should take it. If the thing that repeats is best described as "a ticket like this, every month, and here is what it should say", a rule with a template reads better.

The second deciding row is hosting. If you are on Server or Data Center, we cannot help you and Codedoers can.

What we do differently #

We are a Forge app, which means we run on Atlassian's own infrastructure and your data stays inside your Jira site. Three things follow from the way we built it:

Rules are scoped to one project. The app is off in every project until a project administrator turns it on, and the rules page only ever shows that project's rules. Nothing clatters across every project on the site.

Every occurrence is recorded. The run history lists what was created, what was skipped and what failed, with the failure reason named rather than a silent gap. A schedule that quietly stops is the single most common complaint in this whole app category, so we spent the complexity budget there: a rule cannot fire twice for one occurrence and cannot silently skip one, and an hourly pass recovers any run that was claimed and never executed.

You can see the schedule before you save it. The editor previews the next five occurrences, so a recurrence you got wrong is visible in the editor rather than three weeks later.

You can bring your Automation rules with you. Paste Jira Automation's own exported rules JSON and you get a per-rule report before anything is written.

Who should stay with Repeating Issues for Jira #

Say this plainly, because it is the useful half of any comparison:

• You are on Jira Server or Data Center. We are Cloud only.
• Your team already thinks of recurrence as a property of an issue, and the clone or reopen action is exactly what you want.
• You need to schedule an arbitrary workflow transition on a schedule. Reopening an issue on a cycle is something we do not do.
• You rely on velocity expressions in custom field values, or on iCalendar recurrence rules specifically.
• It works and your team knows it. A working schedule is worth more than a slightly better-fitting one.

How to switch, if that is where you landed #

1. Write down what actually repeats before you touch anything. Open each issue carrying a recurring action and note the summary, the frequency, the next occurrence and the action type.
2. Install us and turn the app on for one project. A site administrator installs from the Marketplace; a project administrator opens Project settings → Apps → Recurring work items and turns it on for that project. Nothing appears anywhere else.
3. Set the working week and your holidays first. Rules that move off a non-working day need this to exist before they can use it.
4. Recreate one rule and preview it. The editor shows the next five occurrences. Check them against what the old schedule was going to do.
5. Let both run for one cycle, then compare the run history against the issues the old app created. Only when they agree should you remove the old recurring actions.
6. Then uninstall. Not before, and not on the day a schedule is due.

Step 5 is the one people skip and the one that catches time zone surprises, which are endemic in this category.

Common questions #

Can I have repeating issues in Jira without an app at all? Yes. Jira Automation's scheduled trigger does it, and for a handful of rules it is the right answer. The limits are the step allowance and the lack of calendar awareness, both covered above. Jira recurring tasks compares all three approaches side by side.

Does either app backfill issues I missed while it was paused? Ours does not, deliberately: resuming a paused rule recomputes the next run from now, so you do not get a pile of overdue tickets the moment you switch it back on.

What happens to my rules if the licence lapses? On our side, scheduled runs stop and both pages say so in a banner. Your rules, settings and history are untouched and resume when the licence does. A schedule that stops without telling anybody is the failure mode we were most determined to avoid.

Is the tier really what I pay for, not my headcount? Yes, on both apps. Atlassian bills Marketplace apps at your Jira user tier, so 11 users and 15 users cost the same. Price your own tier before comparing anything.