Blog ·
Jira scheduling: three different jobs, and which tool does each
Jira scheduling is one phrase covering three unrelated jobs, and picking the wrong tool for yours is the usual reason the answer feels harder than it should be. You are either scheduling when work happens (dates on issues, a timeline, a sprint), scheduling when work is created (the same maintenance ticket appearing every Monday without anybody typing it), or scheduling a reminder about work that already exists. Jira handles the first natively, meters the second, and leaves the third to rules you write yourself. This page sorts out which one you are asking about, then goes deep on the second — the one people arrive here for.
The three jobs, side by side #
| What you mean by "Jira scheduling" | The question you are really asking | Where the answer lives |
|---|---|---|
| Scheduling when work happens | "When is this due, and what order are we doing things in?" | Jira's own start/due dates, timeline and sprint planning — built in, nothing to buy |
| Scheduling when work is created | "How do I stop hand-creating the same ticket every month?" | Jira Automation's Scheduled trigger, or a recurring-issues app |
| Scheduling a reminder | "How do I get nudged about stale or approaching items?" | A Jira Automation rule on a schedule with a JQL query attached |
If you are in row one, you do not need an app and you can stop reading — set the dates and use the planning views Jira ships. Rows two and three are the same machinery, so the rest of this page is about them.
Scheduling when work is created #
This is the recurring-work problem: a quarterly access review, a monthly infrastructure patch round, a weekly report ticket, an onboarding checklist. The work is predictable. Somebody still types it.
There are exactly two shapes of answer in Jira Cloud — a rule inside Jira Automation, or an app whose job is scheduling. They fail in different places, and the difference is what decides which you want.
Option one: Jira Automation's Scheduled trigger #
Automation is included with your Jira plan, so this costs nothing extra to try. Atlassian's own trigger documentation (checked September 2026) describes the trigger in one line:
This flow runs on a specified schedule
You get a fixed interval — the page's own example is "every 7 days" — or a Cron expression when the interval is not that simple. You can also attach a JQL query to the trigger, and the rule's actions then run against whatever that query returns, which is how reminder rules are built. We walked six of these rules through end to end in Jira automation examples, and the cron syntax itself has its own page.
Two things about it are worth knowing before you build your recurring work on it, and both are quoted straight from Atlassian:
- A failing rule turns itself off. "Scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically." Nothing in your backlog announces this. The tickets simply stop arriving, and the first person to notice is usually the auditor.
- Your whole site shares one allowance. Atlassian's usage documentation (checked September 2026) defines a step as "a metered feature that runs within an automation flow" — the trigger, each condition, each action, each branch counts one, whatever the outcome.
The monthly step allowance per Jira Cloud plan, as of September 2026:
| Jira Cloud plan | Automation steps per month |
|---|---|
| Free | 150 per subscription |
| Standard | 400 per user |
| Premium | 750 per user |
| Enterprise | 1,000 per user |
That is a shared pool. The same page states that "If extra usage is disabled and you reach 100% of your total steps allowance", then "your automation flows will stop running until usage resets on your usage billing date" — every flow on the site, not only the greedy one. With extra usage enabled, overage runs at "$0.50 per 1,000 additional steps", which Atlassian says takes effect from December 3, 2026. There is more on what that means for a recurring rule specifically in Jira Automation pricing.
Neither of those is a reason to avoid Automation. They are reasons not to put quiet, must-not-miss recurring work on a mechanism that is shared, metered, and silent when it stops.
Option two: a scheduling app #
The Atlassian Marketplace has a small category of apps whose only job is creating issues on a schedule — The Scheduler is the largest of them, and Recurring Tasks for Jira Cloud and Repeating Issues for Jira sit alongside it. They do their own scheduling rather than driving an Automation rule, so they consume none of the allowance in the table above, and they keep a record of each run.
That is the class Recurring Work Items for Jira belongs to. A rule is a schedule plus an issue template: you write it once, in one Jira project, and the app creates the issue from then on. Every occurrence — created, skipped or failed — is written to that rule's history with the reason, so "why did this not appear" is a question with an answer rather than an investigation.
Which one fits, on the rows that actually differ #
| Jira Automation | A scheduling app | |
|---|---|---|
| Cost | Included with your plan | Free up to 10 users here, then $5.50 per user per year |
| Uses your automation allowance | Yes, every step | No |
| Scope | Site-wide or per project | One project at a time here; site-wide on some apps |
| When it stops working | Disables itself after 10 consecutive failures | Recorded as a failed occurrence in the rule's history |
| Working days and holidays | You express it in cron, or not at all | A setting on the rule |
| Where the template lives | In the rule | In the rule |
| Best for | Anything ad hoc, cross-tool, or event-driven | Predictable recurring work somebody would notice missing |
Who should stay with Jira Automation #
Plenty of teams should, and it is worth saying so plainly:
- Your schedule is simple and your allowance is nowhere near its limit. A weekly rule creating one ticket is a handful of steps a month. Do not buy an app for that.
- The trigger is not really a clock. If the real rule is "when this transitions, do that", Automation is the right tool and a scheduler is not.
- You need it to reach outside Jira — Slack, a webhook, another Atlassian product. Automation connects to those; a scheduling app does not.
- You are on Server or Data Center. Recurring Work Items is a Forge app and is Jira Cloud only.
How to switch, if that is where you landed #
- List the scheduled rules you have. In Jira, the automation list filtered to the Scheduled trigger tells you what is currently on the clock, and its audit log tells you which of them have been failing.
- Move the ones that are quiet and must not miss — compliance reviews, patch rounds, anything with a date somebody signs off. Leave the chatty event-driven rules exactly where they are.
- Rebuild the schedule, not the rule. In an app the schedule is a form: frequency, working-day handling, and the template. The rules page documents every field, and dynamic titles cover the part of the cron rule that was only there to put a date in the summary.
- Turn the old rule off rather than deleting it, and watch one full cycle before you do anything permanent. Both tickets appearing once is a much better problem than neither.
- Check the run history after the first occurrence. If the app cannot tell you what it did, that was the reason for moving and you should find out early.
Common questions #
Does Jira have built-in recurring tasks? Not as a feature by that name. The supported route is an Automation rule on the Scheduled trigger with a Create issue action, which works and is metered like any other rule.
Do scheduled automation rules count against my plan's limit? Yes. Automation is metered in steps, and the trigger, each condition and each action each count one — so a rule's cost is its size multiplied by how often it runs.
Why did my scheduled rule stop running? The two usual causes are that it reached a Failure status for 10 consecutive executions and disabled itself, or that your organisation's pooled allowance hit 100% and every flow stopped until the billing date.
Can I schedule work in one project without affecting others? With Automation, scope is something you set and can get wrong. Recurring Work Items has no site-wide rules at all: a project is enrolled explicitly, and turning it off stops that project and touches no other.
Is this the same as scheduling a Jira report? No — that is the reminder row of the first table. A Scheduled trigger with a JQL query attached is the usual way to build it.