Blog · 18 September 2026

Jira automation examples: six rules, and where each one breaks

Jira automation examples are almost all the same shape: a trigger that starts the rule, an optional condition that narrows it, and one or more actions that do the work. The six below are the ones that come up again and again when the job is recurring work — a scheduled create, a task with its subtasks, a run restricted to a working day, a cron-driven review, a checklist that rides along, and a rule that builds from a saved template. Each is written as trigger → condition → action so you can rebuild it in Project settings → Automation, and each is followed by the part the documentation does not print beside it: what the rule does when it fails, and what it spends out of an allowance shared with every other rule on your site.

What every Jira automation example is built from #

Three parts, in order:

For recurring work the trigger is Scheduled. Atlassian's own trigger documentation (checked September 2026) describes it in a single line: "This flow runs on a specified schedule" — either at a fixed interval, for which the page gives the example "every 7 days", or on a Cron expression for something more involved. The same page notes you can attach a JQL query to the trigger, in which case the rule's actions run against the work items that query returns.

Two details on that page matter more than the rest, and both come back below: the Scheduled trigger has no time-zone setting described anywhere in its documentation, and "Scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically."

You build all of these in the same place: Project settings → Automation → Create rule, or the global Settings → System → Automation for a rule that spans projects.

Example 1: create the same task on a fixed schedule #

The plainest recurring-task rule, and the one most people mean when they search for a Jira automation example.

• Trigger: Scheduled — every 7 days at 09:00
• Condition: none
• Action: Create work item — project, work type, summary, description, assignee

That is a working rule. It is also a rule with one weakness worth knowing before you copy it: every generated item looks identical, because the summary is a literal string. Atlassian's scheduled-trigger documentation for smart values is where {{now}} comes in — {{now.jiraDate}} in the summary or description puts the run's date into the ticket, which is the difference between a usable list and seven rows called "Weekly maintenance".

Where it breaks: nothing in the rule tells you a run was skipped, and the tenth consecutive failure switches the rule off. More on both below.

Example 2: create a task and its subtasks in one rule #

Subtasks are the part people get stuck on, because the rule has to know the key of the item it just created. Atlassian's own knowledge-base article for this (checked September 2026) lists the rule as:

The rule's steps, as the page gives them: When: Scheduled. Then: Create a new (Issue). And: Create variable — create smart value variable {{RecentStoryCreated}}. And: Create a new Sub-task.

The variable holds createdIssue.key — the key of the item created earlier in the same run — and each sub-task sets its Parent Issue field to {{RecentStoryCreated}} so it lands under the right parent. The same page notes this needs project-admin or Jira-admin rights and is Cloud only.

What to watch: the variable exists only inside that one rule. There is no way to reuse it, and if you later split the rule in two, the second half has no way to find what the first half created.

Example 3: create only on the second working day of the month #

This is the example most worth reading carefully, because it is where a scheduled rule meets a calendar.

Atlassian's knowledge-base article for it (checked September 2026) is explicit that the schedule field itself cannot do it: "For this use case, it's not possible to use the basic or advanced scheduling (CRON expressions) in the Scheduled Trigger in automation."

The workaround is to run the rule daily and let a condition decide whether today is the right day:

• Trigger: Scheduled — runs daily at a specified time
• Condition: Smart values condition — first value {{now.jiraDate}} equals {{now.firstBusinessDayOfMonth.plusBusinessDays(1).jiraDate}}
• Action: Create work item

The page's own summary of the result: the work item is created only when today is the second working day of the month.

And then the sentence that decides whether this example is good enough for you:

"This will not consider any non-working holidays" — so a run that lands on that working day when it is a public holiday is still created. — Atlassian Support, Schedule work items creation with Jira Cloud automation, checked September 2026

The page is honest about it and links a feature request titled "When using BusinessDays, we should be able to define the non-working days and public holidays". Until that ships, calendar arithmetic in Automation knows about weekends and not about your holidays.

Where it breaks: the rule reads correctly and produces the wrong date, on the months with a holiday in them. That is the worst kind of failure — it looks like success in the issue list.

Example 4: a quarterly review on a cron expression #

When the fixed interval cannot express the pattern, you switch the trigger to a cron expression — 0 9 ? * MON for every Monday at 09:00, or something like 0 0 0 ? * 2#1 for the first Monday of the month.

Cron is powerful and unforgiving, and we wrote the shape of it, its traps, and what it cannot say in a separate guide to Jira cron expressions. The thing to know here is what the trigger documentation does not say: it describes the fixed-rate form and the cron form, and it does not describe which time zone the schedule is evaluated in. If a 09:00 run has to be 09:00 for a specific team, that is a question to test on your site rather than assume.

Example 5: a scheduled issue that carries a checklist #

If your recurring work has steps inside it, the checklist app you already use may be able to seed them. Issue Checklist's documentation describes the shape: enable Save data to Jira custom fields, then in Project settings → Automation create a rule with the Scheduled trigger, add a Create issue action, set the summary, and populate the checklist text field with formatted text. The page notes a limitation by project type — it works for company-managed projects, with team-managed differing.

Where it breaks: the rule now depends on a custom field owned by another app. Change the checklist app and the automation example that feeds it is the thing that goes quiet.

Example 6: a rule that builds from a saved template #

The last one is not really a separate rule — it is what people reach for when the item they want to create is big: an epic with stories, or a task with eight fields set. A template app stores that structure, and Automation supplies the clock. Issue Templates for Jira's own documentation puts it plainly: "One of available options to create an issue from a template is to use Automation's Scheduled trigger with Create issue action." Easy Templates for Jira says the same in its own words, describing templates applied "through Jira Automation or the REST API to create repeatable work on a schedule".

That works, and it also means the template lives in one place and the schedule lives in another. We went through what that costs in Jira task template: two things that have to agree with each other, where the half that fails quietly is the schedule.

The six side by side #

The two ways a scheduled rule stops without telling you #

Every example above shares these, and neither announces itself.

1. Ten failures in a row switches the rule off. Atlassian's trigger documentation states it as a single line: "Scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically." The rule is then off, and nothing in your backlog says so — the tickets simply stop arriving.

2. Your site has one allowance, and it is shared. Atlassian's usage documentation (checked September 2026) defines a step as "a metered feature that runs within an automation flow" — triggers, conditions, actions, branches and loops each count one, whatever the outcome. The monthly allowance per Jira plan is:

The same page: "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." With extra usage on, overage is "$0.50 per 1,000 additional steps." We walked through what that means for a recurring rule specifically in Jira Automation pricing.

Put those together and you have the honest risk of this whole approach: a recurring rule is a few steps a run, which is nothing — until something else on the site is noisy, the pooled allowance runs out, and your recurring tickets stop along with everything else. The rule did not fail. The pool did.

When a scheduled rule is the wrong shape #

A scheduled rule is the right answer when the recurring work is occasional, the pattern is simple, and you already live in Automation. It is the wrong answer in three specific cases, and they are the three this product was built for:

• The date has to respect your calendar. A rule can shift work off a weekend with a condition like Example 3, and it cannot know your holidays. Recurring work items for Jira takes the working week and a holiday list from the project's own settings — up to 400 dates, one per line, in YYYY-MM-DD — and each rule chooses what a run landing on a non-working day should do: run anyway, move to the next working day, move to the previous one, or skip, with the due date moving alongside.
• You want the schedule to read like English. There is no cron field. You pick daily, weekly on chosen weekdays, monthly on a date, or monthly on a weekday such as the last Friday; the editor shows the next five runs live as you type, which a cron expression can never do.
• You want the run to be visible afterwards. Every run — created, skipped or failed — is recorded in the rule's history with its reason, and a run held back because the previous item is still open is recorded as skipped with the blocking item named.

The trade is real and worth stating: rules here are scoped to one Jira project at a time, so a schedule you want in five projects is five rules. It is a Jira Cloud app, with no Server or Data Center build. The listing is free up to 10 users and $5.50 per user per year above that. Because the app does its own scheduling rather than driving Automation, it consumes none of the steps in the table above — which is the whole point when the pool is what keeps running out. The full editor is documented on the rules page and the project settings on setup.

Who should stay with Jira Automation #

Stay, and do not install anything, if any of these is true:

• Your recurring work is a handful of simple tickets on a predictable schedule.
• Your automation allowance is comfortably clear of its limit and likely to stay there.
• The rule's action is something only Automation can do — a transition, a field edit driven by a JQL result, a chain across service projects. A scheduling app creates work items; it does not replace a general rule engine.
• You are on Jira Server or Data Center. Automation is what you have.

Automation is free with your plan, it is maintained by Atlassian, and for a lot of teams it is genuinely enough. The case for a scheduler is not that Automation is bad — it is that a specific shape of work, calendar-aware and repeating and quiet when it fails, is the shape it handles worst.

Frequently asked questions #

What is the simplest recurring-task automation in Jira? A Scheduled trigger with a Create work item action, as in Example 1. Atlassian's own trigger documentation gives the fixed-interval form as "every 7 days".

How do I create subtasks automatically with the issue? Create the parent, store its key in a smart value variable using createdIssue.key, then create each sub-task with that variable in the Parent Issue field — Example 2 above.

Can a scheduled rule run only on working days? Yes, with a daily trigger and a smart-value condition comparing {{now.jiraDate}} to {{now.firstBusinessDayOfMonth.plusBusinessDays(1).jiraDate}}. It accounts for weekends. Atlassian's own page states that it "will not consider any non-working holidays".

Why did my scheduled rule stop running? Two common causes: it reached a Failure status for 10 consecutive executions and disabled itself, or your organization's pooled automation allowance hit 100% and every flow on the site stopped until the billing date.

Do scheduled automation rules count against my plan limit? Yes. Atlassian meters automation in steps, and the trigger, each condition and each action each count one.