How to create recurring tasks in Jira

Jira is built around one-off issues. There is no native setting that says “create this ticket again every Monday” — so recurring work (stand-ups, sprint ceremonies, monthly reports, backup checks, compliance reviews) tends to get remembered by a human, cloned by hand, or forgotten. There are three real ways to handle it in Jira Cloud: clone the issue by hand each time, build a scheduled Automation for Jira rule, or use a dedicated recurring-issues app like Cadence that creates the issue on its own schedule without touching your Automation quota. Here’s how each one works, and where it breaks down.

Option 1 — Clone the issue by hand

The zero-setup approach: when the task comes around, open last time’s issue and use ⋯ → Clone. It works, and for something that happens rarely it’s fine.

It falls apart the moment the cadence is regular. Someone has to remember, the clone carries over stale field values, and there’s no record that this is a repeating obligation — so when that person is on holiday, the task simply doesn’t happen. Recurring work should not depend on a person’s memory.

Option 2 — Automation for Jira scheduled rule

Jira’s built-in Automation can do this with a Scheduled trigger: run on a cron/interval, then a Create issue (or Clone issue) action. This is the native, no-app answer and it’s genuinely useful for simple, single-issue recurrences.

Where it gets uncomfortable:

• It burns your automation limit — and that meter is changing. Every scheduled run counts against your plan’s monthly automation quota. A handful of daily recurrences quietly eats into the budget you’d rather spend on real workflow automation, and from 3 December 2026 Atlassian is switching Automation to step-based metering, where even a rule that fires and finds nothing to do still spends allowance.
• Trees are painful. Recreating a full epic → story → sub-task structure means a rule that creates the parent, then branches to create and re-parent each child — fiddly to build and easy to break.
• The logic lives in the wrong place. The recurrence sits in a global/project automation area that admins own, not somewhere the team managing the work can see “these are our recurring items” at a glance.
• Timezones and month-ends need care. “First business day of the month” or “last Friday” across daylight-saving changes is doable but easy to get subtly wrong.

If your recurring need is one simple issue and you have automation headroom, Automation for Jira is a perfectly reasonable choice.

Option 3 — A recurring-issues app

Once recurrence is a real part of how the team works — multiple schedules, full templates, or you don’t want it on the automation meter — a dedicated app is cleaner. This is the category Cadence is built for: you define a schedule on the project, pick the fields or a saved template, and it creates the issue at every occurrence automatically.

What a purpose-built tool gets you over a scheduled rule:

• Real calendar cadences — daily, chosen weekdays, monthly by day or nth-weekday, first/last business day (with your own holiday list), or a cron expression — all timezone- and daylight-saving-correct.
• Whole hierarchies in one go — recur a saved epic → story → sub-task template, not just a single issue.
• Off the automation meter — it runs on its own schedule, so it doesn’t spend your Automation quota.
• Attribution and history — each created issue has a real reporter, and there’s a run history so you can see it actually fired (and catch it up if the platform ever misses a window).

Which should you use?

• One-off or very rare? Clone by hand.
• One simple issue, on a schedule, with automation budget to spare? Automation for Jira.
• Several schedules, full templates, business-day/holiday rules, or you want it off the meter? A recurring-issues app like Cadence (see the best recurring-issue apps for Jira).

The honest rule of thumb: start native, and move to a dedicated tool the moment recurrence becomes something you’re maintaining rather than something you set once.