Blog ·

Issue Templates for Jira: cost, features, and the clock

Issue Templates for Jira is Deviniti's template app for Jira Cloud: it stores a work item — or a whole epic with its stories, sub-tasks and linked items — as a reusable template, then rebuilds it with the fields already filled in. If you are searching for issue templates for jira, you are usually after three answers: what it actually stores, what it costs once your site grows past a handful of people, and whether it can make the work appear on its own. The first two are below, from Deviniti's own product page and the app's Atlassian Marketplace pricing as of September 2026. The third is the one worth reading twice, and Deviniti's documentation answers it plainly: the app holds the content, and Jira Automation holds the clock.

The short verdict #

What Issue Templates for Jira does #

Deviniti's product page (checked September 2026) describes an app aimed squarely at repetition without a clock. Its stated capabilities:

It also carries the Atlassian Marketplace security credentials you would expect of an app at this size: it is a participant in the Marketplace Security Bug Bounty Program and is Cloud Fortified.

That is a deep, well-built template engine. Nothing below is a criticism of it; the rest of this page is about the two questions its feature list does not answer.

What Issue Templates for Jira costs #

Cloud pricing as published on the Atlassian Marketplace for the app's Standard edition, and on Deviniti's own pricing page for Advanced, as of September 2026. Annual list prices, in USD:

Team size Standard (annual) Advanced (annual)
Up to 10 users $0 $0
15 users $162
25 users $270
50 users $540 $700
100 users $1,080 $1,400
250 users $2,050 $2,650
500 users $2,690 $3,450
1,000 users $4,290 $5,450

Three things about that table are easy to misread:

Free at 10 users is real, and it stops abruptly. At 10 users the app costs nothing, monthly or annual. At 15 it is $162 a year. That is not a bug in the pricing; it is Atlassian's standard shape, where the first paid tier is billed per user from the first user rather than from the eleventh. Budget for it before your eleventh person joins.

You are billed on your Jira user count, not on who uses templates. Deviniti's pricing FAQ is explicit: "Jira Cloud apps are priced based on the maximum users of the Jira products on your instance", and gives the example of a site with Jira Software at 50 users and Jira Service Management at 10 agents paying "the 50-user price for apps". Two people writing templates on a 200-seat site pay the 250-user tier.

Advanced is a separate decision. Deviniti sells Standard and Advanced cloud editions, and the gap widens with size — about $160 a year at 50 users, over $1,100 at 1,000. Deviniti's pricing page also notes that "Annual subscriptions may offer a discount depending on the number of users purchased", and that "Academic, community, and open source licenses are available to qualifying organizations."

On evaluation, Deviniti's FAQ states that for cloud apps you "cannot extend your free evaluation period", which "is a minimum of 30 days and ends on the second billing cycle after you first subscribe to the app."

Where the schedule lives #

This is the part the feature list does not make obvious, and Deviniti says it in its own documentation rather than leaving you to discover it:

"One of available options to create an issue from a template is to use Automation's Scheduled trigger with Create issue action."

— Issue Templates for Jira cloud documentation, checked September 2026

The same page adds that applying a template to the newly created item "is possible only if you change Create issue action's properties", by setting an issue.templates.automation property on the action's JSON.

So the schedule is a Jira Automation rule, the content is a Deviniti template, and the link between them is a property inside the rule's advanced JSON field. That arrangement works — plenty of teams run it — but it has a shape worth naming before you build on it:

Who should stay with Issue Templates for Jira #

Most readers of this page, genuinely:

When a recurring rule fits better #

Recurring Work Items for Jira does not store epic hierarchies or linked-item graphs, and it is not trying to. It does one thing: a rule is the schedule and the item, in one record.

Issue Templates for Jira Recurring Work Items for Jira
Stores a reusable structure Yes, including epics and linked items Yes — item plus ordered subtasks
Applied by a person Yes, from the Create screen Not the point of it
Creates items on a schedule Via a Jira Automation rule Built in
Where the schedule lives A separate Automation rule The same rule as the content
Jira Automation quota used Yes, per scheduled run None
Dynamic titles and dates Variables Tokens
Working days and holidays Handled by the rule you write Built into the schedule
Per-run record of what happened Automation audit log Run history per rule, with the reason
Scope Site-wide template library One project at a time
Free at 10 users Yes Yes, then $5.50 per user per year

The dividing line is not features, it is what fails quietly. A template nobody applies is visibly unapplied. A schedule that stopped firing looks identical to a quarter with nothing due, which is why our rules table shows each rule's next run and its health, and why every occurrence — created, skipped or failed — is written to that rule's history with the reason.

How to move one repeating template to a schedule #

You do not have to choose globally. Take the single template whose entire purpose is repetition — usually the compliance review or the release checklist — and try it:

  1. Open the template and write down what actually varies. Almost always: the month or quarter in the title, and the due date. Everything else is fixed text.
  2. Turn the project on in the app's project settings, and say who may schedule. Nothing happens in a project until it is enrolled, and turning it off stops that project without touching any other.
  3. Write the rule: item type, summary, description, due date, assignee, reporter, priority, labels, and the sub-tasks in order. Put the varying parts in as tokens rather than editing the title every cycle.
  4. Check the preview. The editor shows the next runs before you save, which is the one thing a cron expression can never do for you.
  5. Leave the Deviniti template in place for the on-demand uses. The two do not conflict; you are only removing the Automation rule that was standing in for a clock.

If after a cycle the rule is doing the job, repeat it for the next repeating template. If it is not, you have lost one rule and changed nothing else.

The honest summary #

Issue Templates for Jira is a strong template engine with a real free tier and a pricing ladder that starts costing at 15 users, not 11. It stores structure better than a scheduling app does. What it does not have is its own clock, and its own documentation points you at Jira Automation for that — which is the right answer when a person presses Create, and the expensive answer when the whole point of the template is that nobody should have to.

For the wider comparison of clone, template app, Automation rule and recurring rule side by side, see Jira task template. For the other template app in this niche, see Easy Templates for Jira.