Three ways to do it, and the six things the built-in option quietly leaves behind.
Recurring work is the most ordinary thing a team has - the weekly report, the monthly access review, the quarterly backup test - and Jira handles it less gracefully than you would expect. Here are the three routes, with the catch in each.
Open the work item, click the lightning bolt for Automation, or click the Due date field, and choose Set to recur. You pick a schedule, a trigger and an expiry date.
It is free and takes about thirty seconds. Two things are worth knowing before you rely on it.
Where it goes afterwards. Setting recurrence creates a flow behind the scenes, which is why people often cannot find it again later. It is not on the work item. It lives in Project settings → Automation → Flows, filtered by the label Recurring, and that is also where you delete or disable it. Worth writing down somewhere before the person who set it up leaves and nobody can work out where the weekly tickets come from.
What it does not copy. This is the one that bites. Atlassian's documentation is explicit that a recurring copy does not include attachments, web links, linked work items, Confluence pages, Confluence whiteboards, or Loom videos. Fields and child work items do come across.
So if your recurring maintenance task is the one with the SOP attached, or the one linked to the runbook page, every copy after the first arrives stripped - and the person doing the work in month three has no idea anything is missing. They just do it from memory. Put the procedure in the description, or reference it from a field that survives, rather than attaching it to the item you set to recur.
A scheduled rule gives you far more control: conditions, branches, different work item types, subtasks created in a particular order. If the recurring thing is complicated, this is the right tool.
Budget the steps. Atlassian counts "a single executed part of an automation flow, including triggers, conditions, actions, branches, and loops" as one step, and the monthly allowance is pooled at the organisation level: 150 on Free, 400 per user on Standard, 750 per user on Premium, 1,000 per user on Enterprise. A rule that creates a parent plus five subtasks is not one step - it is the trigger, the create, and each child, every single time it fires. Forty weekly schedules shaped like that will eat a Free or small Standard allowance long before anyone connects the throttling to the maintenance calendar.
Mind the actor. The default flow actor in Jira automation is the user called Automation for Jira, so history and notifications attribute the creation to that rather than to a person. Usually that is what you want. If you change the actor to a specific human to make the audit trail read better, you have tied the schedule to that person's permissions, and Jira will tell you so with "Either you or the rule actor for this rule is missing some required permissions" - sometimes at save time, and sometimes much later when their access changes. That is a slow failure: the schedule stays switched on and simply stops producing anything.
Apps in this category exist because the two options above sit at opposite extremes: one is a thirty-second toggle that drops half the content, the other is a rule builder you have to maintain and pay for in steps. Several Marketplace apps fill the middle.
Disclosure: I build one of them. Simple Recurring Issues adds a panel to the work item. You pick how often and at what hour in your own timezone - no cron expression and no rule builder - and it creates a fresh copy on that schedule with its subtasks. Each schedule shows its next run time and a history of what it has created, so you can confirm it is working rather than hope it is. It runs entirely on Atlassian Forge, so no issue data leaves your site, and it is free for sites of up to ten users.