How to create recurring issues in Jira

Jira has no native repeating issue. The request has been open since 2005. Here is every way to get one, starting with the ones that cost nothing.

Why there is no button for this

JRACLOUD-5185 asks for recurring issues in Jira Cloud. It is one of the oldest open requests in the tracker. In the meantime, everything below is somebody working around its absence.

Option 1 — a Jira automation rule. Free, and right for most people.

The whole recipe, because most articles about this stop before the useful part:

1. Project settings → Automation → Create rule. A project-scoped rule is enough unless you need the same job in several projects, in which case make it multi-project at the global level and accept that it will be harder to find later.
2. Trigger: Scheduled. Choose the fixed-rate form — every 1 day, every 7 days — and set a start time. Avoid the cron form if you can; see the timezone problem, which is the single most common reason these rules misbehave.
3. Leave the JQL box empty unless you want the rule to run once per matching issue. A scheduled trigger with JQL iterates; a scheduled trigger without it fires once. Filling it in by accident is how one ticket a week becomes forty.
4. Action: Create issue. Fill in every field your project marks required, including any custom ones — a rule that silently fails on a required field is the second most common complaint about this approach, and the failure only appears in the audit log.
5. Put the date in the summary with a smart value such as {{now.format("yyyy-MM-dd")}}, so the fiftieth copy is distinguishable from the forty-ninth.
6. Turn it on, then open the audit log after the first run and read it.

When this is the right answer: a handful of jobs, a simple schedule, one timezone, and somebody who will notice if a rule stops. That describes most teams, and if it describes yours you should stop here and not buy anything.

Option 2 — the REST API on a schedule you control. Free, if you have somewhere to run it.

A short script that POSTs to /rest/api/3/issue, run from cron, a CI schedule, or any scheduler you already operate. Total control over dates, holidays and payloads, and no platform limits to work around.

What it costs you, honestly:

• Somewhere to run it that is up at 08:00, which is the part people underestimate — a laptop is not a scheduler.
• An API token belonging to a person, which becomes a problem the day that person leaves.
• Failure handling nobody writes on the first pass: the run that is skipped because the machine rebooted, and the run that fires twice because it was retried.

Option 3 — a Marketplace app

There are several, ours among them. The honest summary of what you are paying for is: a schedule editor that understands “the last Friday of the month”, a preview of the next few runs before you save, a record of what ran, and somebody to email when it does not. None of that is impossible in options 1 and 2. It is all tedious in options 1 and 2.

What to check before you buy any of them, including ours:

The thing that breaks all three

Month-end. “The 31st” does not exist in four months of the year, and every implementation has to decide whether that means skip, use the last day, or roll into the next month — and most of them decide silently. Whatever route you take, create one job for the 31st and look at what it does in February before you trust the rest.

Where this comes from

We build Recurring Issues & Reminders for Jira, which is one of the options above. We have tried to write this page so it is useful to somebody who picks one of the other ones — if the automation rule does what you need, use the automation rule.

Something here wrong or out of date? [email protected]. Written reply, one business day, and corrections go up with the date on them.