A maintenance Epic on the first of every month. A release checklist every sprint. A quarterly access review with the same six tasks.
The work repeats, the structure repeats, and somebody rebuilds it by hand each time. People have been asking how to automate it for years: in 2023, in a 2025 thread with over 30,000 views, and for the whole Epic with its tasks more recently still.
This article is for Jira admins: how to repeat a whole Epic, with its Stories, Tasks and Sub-tasks, on a schedule in Jira Cloud, what each way copies and costs, and the traps the threads keep hitting. We ran every option below on a Jira Cloud site in October 2026.
As of October 2026, recurring work in Jira Cloud always runs on Automation: either Set to recur on a work item, which creates a "Clone on a schedule" flow for it, or a rule with a Scheduled trigger that you build yourself.
The same Epic every month. The question is where its structure lives: in the rule, as one action per work item, or in a template that the rule only starts.
The built-in option: Set to recur
Open the work item, select the Automation (lightning bolt) button or the Due date field, and choose Set to recur (Atlassian docs: Schedule work items to recur). You pick Daily, Every weekday, Weekly, Every 2 weeks or Monthly, whether it recurs when scheduled or when the work item is completed, and an end date. Jira saves it as a flow named "Clone on a schedule".
Set to recur on an Epic: monthly, on the 1st, when scheduled.
For a single recurring task, this is the whole answer, no app needed. On an Epic it copies less than the threads hope. We set it on an Epic with a Story and a Task, each with a Sub-task and the Task linked to the Story. One run gave us:
- the Epic, the Story and the Task, under the new Epic;
- no Sub-tasks and no link between the new Task and Story (the docs also leave out attachments and web links);
- the same name as the original, with no month in it;
- one Due date for every copy, a month after the run.
Your own Scheduled rule: one action per work item
For full control, build the rule yourself on the Scheduled trigger, which "can run the flow at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules."
- In Settings → System → Global automation, create a rule with the Scheduled trigger. On the Basic tab, set Run flow every 1 Months, On the First day of month, and a time.
- Leave Run a JQL search and execute actions for each work item in the query unticked. More on that box below.
- Add Create work item for the Epic. A Summary of
Monthly maintenance – {{now.format("MMMM yyyy")}} gave us "Monthly maintenance – October 2026". - Add Create variable
epicKey = {{createdIssue.key}}, because {{createdIssue}} always points at the latest item. - Add each Story or Task with Parent =
{{epicKey}} and its own Due date, such as {{now.plusDays(14)}}; then a variable for its key and its Sub-tasks with that variable as Parent.
The Scheduled trigger's Basic tab: every month, on the first day, at 9:00, with the JQL box unticked.
Atlassian documents this pattern (KB: create Stories, Tasks and their Sub-tasks), and we built it step by step in How to create a Jira Epic with all its Stories and subtasks in one step.
Our native rule: the Epic, a Story and a Task, each with a Sub-task. Eight actions after the trigger.
Each run gave us a new Epic named for the month, Sub-tasks included, with Due dates counted from the run day. Linking the new Task to the new Story took one more piece: a Branch of type JQL with key = {{taskKey}}, and inside it Link work items ("relates to", {{storyKey}}). A Scheduled rule without JQL starts with no work item in focus, so there is nothing to link from without the branch.
Two details. {{now}} is in UTC (Atlassian docs), so a rule that runs just after midnight on the first, in a time zone ahead of UTC, can still name the previous month: schedule it a few hours into the day. And to test without waiting a month, select ••• → Run scheduled flow now. It only works on an enabled rule, so the rule will also run on its schedule from then on.
The three traps
1. The JQL box multiplies your Epics. With Run a JQL search and execute actions for each work item in the query ticked, Atlassian's docs say the actions "will execute on the work items included in the query", so one run can create one Epic per match. A rule that only creates work needs it unticked.
2. The Automation action Clone work item doesn't clone the tree. The manual Clone in a work item's menu can include child work items, and Set to recur copies them too, but a rule's Clone work item action "will not clone work item links or comments" (actions reference), and Atlassian's recipe for Sub-tasks adds a separate branch with another Clone (KB).
3. Every run costs steps. Automation usage is now counted in steps: "Every trigger, condition, action, branch, and loop that runs in a flow counts as a step toward your usage", and from 3 December 2026 usage above the allowance is billed at $0.50 per 1,000 steps (How is my usage calculated). Our native rule logged 9 components per run for the five-item tree, 11 with the link. Once a month that's small, but it grows with every item and every team that copies the rule, and a single rule can hold at most 65 conditions, branches and actions (service limits).
The scorecard
Three ways to repeat the same five-item Epic, as we ran them. Counts per run come from each flow's audit log.
Option | What one run creates | Where the structure lives | Audit log entries per run |
|---|
Set to recur | The Epic and its direct children; no Sub-tasks, no links, one Due date for all | The original work items | 8 |
Your own Scheduled rule with variables | The whole tree; links need a branch each | The rule, one action per work item | 9 (11 with one link) |
Scheduled rule + a template app's action | The whole tree, with the links between its items recreated between the new copies | The template's work items | 2 (4 with the month in the name) |
When the structure outgrows the rule: a template
Full disclosure: we build Templify at Terano Apps, and the steps below use it. Everything above works without it.
With a template, the Epic and its children are ordinary work items you edit, and the rule only says when to copy them.
Step 1: Build the Epic once and mark it as a template
Create the Epic with its Stories, Tasks, Sub-tasks and links, then mark it as a template from its Issue Templates panel. On the Dynamic fields tab of the Epic and of each child, set relative Due dates: we used now + 21d, now + 14d and now + 7d.
The template: an Epic with a Story and a Task, and a Due date counted from the day each copy is made.
Step 2: A Scheduled rule with one action
Use the same Scheduled trigger, JQL box unticked, and add Create issue from template with the template picked; an empty Target project means the template's space. For the month in the Epic's name, add a JQL branch such as project = OPS AND issuetype = Epic AND summary ~ "Monthly maintenance" AND key != OPS-12 AND created >= -5m with Edit work item fields setting the Summary to Monthly maintenance – {{now.format("MMMM yyyy")}}. Keep key != <your template> in the query: in our first test the template was only minutes old, matched, and got renamed too.
Scheduled, then Create issue from template, then a JQL branch that adds the month to the new Epic's name.
Step 3: What one run creates
One run created the Epic, the Story and the Task with their Sub-tasks, Due dates 21, 14 and 7 days after the run, and the Task linked to the new Story rather than to the template's.
"Monthly maintenance – October 2026" with its Story and Task, due on November 12, three weeks after the run.
Where it ends: text placeholders such as {Version:textfield} stay as written when a rule creates the work, since no one is there to fill them in. Keep them out of templates you schedule.
Try it on the Atlassian Marketplace: Templify →
Where this lands in practice
- One repeating task (a monthly report, a weekly check): Set to recur. No app needed.
- An Epic with Sub-tasks, links or staggered Due dates: your own Scheduled rule with variables. Budget one entry per work item, one more for each item with children (its variable), plus one for the trigger.
- An Epic whose checklist keeps changing, or that several teams reuse: keep the structure as a template and let the rule only say when.
Quick answers
Can Jira Cloud create recurring tasks natively?
Yes. Set to recur on a work item creates a "Clone on a schedule" flow for it, and you can also build a rule with a Scheduled trigger and a Create work item action.
Does Set to recur copy Sub-tasks?
In our test on an Epic, no: it copied the Epic and its direct children, without their Sub-tasks and without the links between them.
How do I stop a recurring rule from creating duplicates?
Most often by unticking Run a JQL search and execute actions for each work item in the query. With it ticked, the actions run for every work item the query returns. Also check you don't have two flows for the same work, such as Set to recur plus your own rule.
That's the map as we found it in October 2026. How do you run your recurring work: Set to recur, one rule per checklist, or something else?
Michał Krysiuk, Terano Apps
