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 #
- You need a structure to reappear complete — an epic with its stories, a task with its sub-tasks, a description with the same eight headings — and a person is there to press Create? Issue Templates for Jira is built for exactly that, and it is free at up to 10 users.
- Your Jira site is well past 10 users and templates are applied by hand a few times a week? Look at the tier table below before you assume the free edition still covers you; the jump at 15 users is the one that surprises people.
- The template's whole purpose is that it repeats — the monthly access review, the quarterly DR test, the Friday release checklist? You are about to maintain two things that must agree with each other: a template in one app and a schedule in another. A recurring rule keeps both in one record.
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:
- Whole structures, not single items. "Create Jira issues with already pre-populated fields, sub-tasks, and linked issues", and "Easily clone the whole Epics from templates."
- Dynamic content. Templates support variables so that "tickets match your project's needs", drawn from a range of supported fields.
- Smart Defaults, which "copy field values from parent issues to their subtasks", and calculate "the date fields based on the current time to avoid mistakes".
- Applying a template to an item that already exists, "to standardize content across your Jira instance" — useful when a ticket arrives from a customer portal half-filled.
- Visibility and default templates, so that "only authorized team members use templates" and a large library stays manageable.
- JQL searchers, to track templates and the items created from them.
- A REST API, for integration with "external tools, such as Zapier, Jenkins, or Bitbucket."
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:
- Two records have to agree. Rename or retire a template and a rule somewhere else is now pointing at nothing. Nothing in the template tells you which rules use it.
- The schedule consumes your Jira Automation allowance, not the app's. Our Jira Automation pricing breakdown is the honest version of when that starts to matter.
- Failures are reported where the rule is, not where the template is. Atlassian's own documentation notes that scheduled flows reaching a failure status for ten consecutive executions disable themselves — a silence that looks exactly like a month with nothing due.
- The cron field is unforgiving. If you go this route, read Jira cron expression first; the traps there cost more time than the setup does.
Who should stay with Issue Templates for Jira #
Most readers of this page, genuinely:
- You apply templates by hand, when a request arrives or a project kicks off. A scheduler adds nothing you need; a human is the trigger and that is correct.
- The structure is the hard part. Deep epic hierarchies, linked items, Assets field values, variables, autocomplete — this is a mature app and it goes further than a scheduling tool will.
- You need templates across many projects and many item types, with availability rules about who may use which. That is what Advanced is for.
- You already have the Automation rules working. A working arrangement is worth more than a tidier one. Replace it when it breaks, not before.
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:
- 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.
- 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.
- 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.
- 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.
- 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.