How to create recurring Jira issues without using Automation executions

The usual way to make issues recur in Jira is a scheduled Automation rule: fire on a cron, create the issue, done. It works — until your automation usage starts climbing. Recurring work is, by definition, work that happens often, and every time that rule fires it spends from your automation execution allowance — the same pool your real workflow automation draws on. The direct fix is to stop running recurrence as an Automation rule at all: a dedicated recurring-issues app like Cadence schedules and creates the issues itself, on its own timer, so recurrence never touches your Automation quota — under today’s rule-run metering, or the step-based metering Atlassian is rolling out from 3 December 2026.

Why recurring rules cost you quota

Jira Cloud Automation has a monthly execution limit that scales with your plan and user tier. Most rules barely register against it — they fire on the odd transition or comment. Recurring schedules are different:

• They fire on a timer, not on demand. A “create this issue every morning” rule runs whether or not anything happened — roughly 30 runs a month per schedule, before you count anything else.
• Multi-project and global rules draw on a shared limit. Recur the same kind of issue across ten projects and the executions add up fast.
• Hitting the limit stops everything — for now. Go over today’s monthly limit and every rule on the site stops running until it resets at the start of next month; a paused recurring rule means the issue you depend on simply doesn’t get created that day, silently, at the worst time.
• The meter itself is about to get stricter. Atlassian has announced that from 3 December 2026, Automation moves from counting rule runs to counting individual steps — every trigger, condition, action and branch counts on its own, and a scheduled rule still burns steps on the days it matches nothing. Recurring schedules get more expensive under the new model, not less, and by default usage past your allowance is billed rather than simply stopped.

So the more you lean on Automation for recurrence, the more of your quota goes to the most predictable work you have — and the more you risk a missed run when the limit bites.

Recurring off the meter

A dedicated recurring-issues app schedules and creates the issues itself, on its own timer, instead of running as an Automation rule. The recurrence is independent of Jira Automation, so it doesn’t touch your execution limit at all.

Cadence works this way: you define the schedule, and it creates the recurring issues on its own cadence — without consuming any automation executions. Your quota stays free for the rules that genuinely need it. That holds regardless of which metering model Jira Automation uses — rule runs today, individual steps from 3 December 2026 — because Cadence was never drawing from that pool in the first place.

Why that matters beyond the quota:

• No competition for executions — recurrence and your real automation don’t draw on the same limit.
• No throttling or billing surprises — a recurring issue won’t quietly stop appearing, and you won’t rack up step-overage charges, because an unrelated busy month blew the automation budget.
• Reliability by design — the schedule is the app’s whole job, so it’s built to fire and create dependably.

The general how-to for setting these up is in how to create recurring tasks in Jira, and if your recurrence needs to respect working days, see recurring Jira issues on business days.

Which should you use?

• A rare recurrence and plenty of automation headroom? A scheduled Automation rule is fine.
• Frequent recurrence, many projects, or automation quota you’d rather protect? Recur off the meter with a dedicated app like Cadence — the recurring work stops competing with your real automation for executions.