Recurring tickets in Jira Service Management after Automation step billing

From 3 December, Jira Automation bills by the step. For most service desks a recurring ticket costs almost nothing. The real risks are elsewhere. Here is the arithmetic, cheaper recipes, and when you need something else.

By Rolf Eriksen 21 October 2026 19 min read

Checked against Atlassian’s pages on 20 October 2026 · Next review 2 November 2026 · We make an app for this (disclosure)

On Jira Service Management Standard and above, a recurring ticket costs almost nothing in Automation steps. Five agents on Standard bring 15,000 steps a month into the pool. A monthly ticket uses 2. A ticket on the 2nd business day, built the way Atlassian’s knowledge base shows, uses about 62. Estimated

Free is different. Jira Service Management Free brings 1,250 steps for the whole organisation, and daily checks add up: six of them use about 371.

The real risks are elsewhere:

• The pool is shared. Every flow in your organisation draws on one pool, across all apps and sites.
• The cliff. With extra usage off, every flow stops when the pool runs out. Events in between are not replayed.
• The clock. A flow runs on one clock, set by its admin. The Basic schedule’s preview keeps 09:00 in the time zone you pick (we have not run one across a clock change). A cron line, which the one-flow business-day recipes need, runs in UTC, so its 09:00 moves by an hour twice a year unless you build around it.
• Ownership. Only admins build flows, and Set to recur is for agents. A customer cannot own a schedule.

Automation used to count whole flow runs, with limits per app and per plan, and Enterprise had no limit. It now counts steps, from one pool per organisation, and billing for extra usage starts on 3 December 2026. Atlassian says billing begins that day for most meters, that the timing can depend on the capability and billing cadence, and that it will tell each organisation its date.

Inside your allowance there is nothing to pay. Over it, extra usage costs $0.50 per 1,000 steps, so 10,000 steps over is $5. The money is small for most desks. What happens when extra usage is off is not.

Allowances

Each plan adds to the pool. Paid plans add an amount per user, Free plans a fixed amount per subscription.

Choose your plans and your recurring tickets. The answer is an estimate from Atlassian’s counting rules, not a bill. The calculator runs in your browser. Nothing you type is sent anywhere or saved.

Atlassian has its own usage calculator for the whole organisation. This one is only about recurring tickets, and it shows the recipes behind the numbers.

Three examples

• A small desk on Free. Jira Service Management Free has 1,250 steps. Six tickets on the 2nd business day by Atlassian’s daily check, plus four weekly ones, use about 406 steps a month: 32.5% of the pool. With the three-day window instead, about 76.8 (6.1%).
• A mid-sized organisation. Jira Service Management Standard with 8 agents, plus Jira and Confluence Standard with 25 users each, pool 36,500 steps. Thirty recurring tickets (10 every weekday, 10 first-Monday Basic schedules, 10 monthly) use about 474.8: 1.3%.
• The same small desk, busier. Add 1,100 steps of other flows to the first example and it uses 1,506, 256 over. Extra usage costs about $0.13 a month. With extra usage off, every flow stops on about day 26 of the usage month instead.

One recurring ticket per row, with one action, created at 09:00. The middle columns are Automation. The last is our app, which does not use Automation at all.

Set to recur figures take each run as a scheduled trigger plus one clone, the parts its doc lists. We have not measured one yet.

“Cheapest recipe we list” means just that, not the cheapest there is. The first Monday is a Basic monthly schedule: no condition, 2 steps a month. The last business day is the Quartz cron form LW (last weekday of the month), also 2. Automation accepted LW when we saved it, but it had not come due before our test ended, so we have not seen it fire. Two other Quartz forms, 3#3 and 20W, fired on time.

In Recurring Requests, the portal customer sets up each schedule from a request they raised, once an admin turns scheduling on. There are no admin or agent schedules, and it does not assign or transition. Every day and every weekday need the admin to allow a 1-day gap between repeats. The default is 7 days.

Most scheduler apps on the Marketplace run outside Automation too, so their schedules also use 0 steps. Ours differs in who owns the schedule: the portal customer.

Every step count below is Estimated: it follows Atlassian’s rules, and the Usage meter did not show our test runs when we looked. What our test flows did show, run by run, is which steps ran. Where we say so, it is Observed in the audit log. When the meter shows a count, its badge changes to Measured and the changelog says so.

Basic schedule or cron

Automation’s scheduled trigger has two tabs. The Basic tab repeats every so many minutes, hours, days, weeks or months, at a time in a time zone you pick, by default your own. Weekly, it shows a button for each day; we did not try choosing more than one. Monthly, it offers the first or last day, the first to fourth or last of a weekday, or a date. It has no business-day option. Its preview showed 09:00 Oslo time on both sides of the March change (GMT+1, then GMT+2), and the first run after the October change at 09:00 GMT+1, although we set it up on summer time. We did not save or run a Basic schedule.

The Advanced tab takes one cron line, seconds first, and says that cron lines run in UTC. Ours fired at the UTC times. 0 0 9 1 * ? is 09:00 UTC on the 1st of every month. Either way, a monthly ticket costs 2 steps a month: the trigger and the action. Our monthly cron flow ran exactly those two, each time. Observed in the audit log

Automation also accepted the Quartz forms MON#1 (first Monday), 6L (last Friday), LW (last weekday of the month) and 1W (first weekday), each 2 steps a month with no condition. Days of the week count from Sunday = 1: our 3#3 fired on Tuesday 20 October, the third Tuesday. 3#3 and 20W fired on time; the other four had not come due before the test ended.

Conditions

A condition costs one step every time it runs, also when it says no. A failed condition ends the run: our flows ran the trigger and the condition, and not the action after it. Observed in the audit log Atlassian’s exclude-a-date KB says such a run shows NO ACTIONS PERFORMED; on our site the audit log called it Success. Both are charged. A JQL search that finds nothing ends the run at the trigger: 1 step, shown as No actions performed. So a daily check costs 2 steps a day, about 30 days a month, to create one ticket. That is the 62.

The three-day window

The Nth business day of a month always falls inside the same three days. The 2nd business day is always the 2nd, 3rd or 4th. So run the check on those three days only. We saw no way to pick days 2 to 4 in one Basic schedule, so this is a cron line, in UTC:

Trigger:   Scheduled, Advanced (cron)  0 0 9 2-4 * ?
Condition: {{now.jiraDate}} equals
           {{now.firstBusinessDayOfMonth.plusBusinessDays(1).jiraDate}}
Action:    Create work item

The condition is the one in Atlassian’s KB. That is 3 runs of 2 steps plus the action: 7 steps a month instead of about 62. Our test flows ran that shape: the trigger and the condition on a day that was not the business day, and the trigger, the condition and the action on one that was. Observed in the audit log For the Nth business day, start the window on day N + 2 × floor((N − 1) ÷ 5) and change plusBusinessDays(1) to N − 1:

Without cron, the same window is three Basic monthly flows, on the 2nd, the 3rd and the 4th (“A date”), each with the same check. That is the same 7 steps a month, at 09:00 in the time zone you pick, but three flows to keep in step instead of one. We have not built it.

The last business day is always between the 26th and the 31st. Use 0 0 9 26-31 * ? with {{now.lastBusinessDayOfMonth.jiraDate}}: about 11.9 steps a month. Or use 0 0 9 LW * ?, the last weekday, with no condition: 2 steps a month, once you have seen it fire on your site. For the first business day, 0 0 9 1W * ? does the same. Without cron, two Basic monthly flows, on the last day and on the last Friday, each with a check that only one of them passes, come to 5 steps a month. We have not built that either.

Business days here are Monday to Friday. Automation does not know your public holidays. To skip dates you list, add a condition: {{now.jiraDate}} does not match the regular expression 2026-12-25|2027-01-01. Atlassian’s KB uses the same kind of condition to skip times of day. We have not tested it with dates yet. It costs one more step a run.

Keeping 09:00 local all year

If the Basic tab can do the job, pick your time zone there. Its preview keeps 09:00 local when the clocks change, at no extra steps; we have not run a Basic schedule across a change. That covers every day, chosen weekdays, every few weeks or months, a date, and the first to fourth or last of a weekday. For several weekdays, we did not try choosing more than one day in a flow; if the tab takes only one, a weekly flow per day costs the same steps. A daily check can run on the Basic tab too, and so can a window, as one flow per day.

The rest need a cron line, or one Basic flow for each day the ticket can fall on: the three-day windows, days 26 to 31, LW, 1W, and MON#1 or 6L if you use them. A cron line runs in UTC, so a ticket set for 09:00 in Oslo arrives at 08:00 or 10:00 for half the year. To keep it at 09:00, run the trigger at both UTC hours that can be 09:00 local, and let a condition pick the right one:

Trigger:   Scheduled, Advanced (cron)  0 0 7,8 2-4 * ?
Condition: {{now.convertToTimeZone("Europe/Oslo").format("HH")}} equals 09
Condition: {{now.jiraDate}} equals
           {{now.firstBusinessDayOfMonth.plusBusinessDays(1).jiraDate}}
Action:    Create work item

London is 8,9 and New York 13,14. Both smart values are on Atlassian’s date and time page. We have not run this form yet.

It costs more. Each day the trigger fires twice, and each firing checks the hour: 4 steps, plus any date check, plus the action. The 2nd-business-day window goes from 7 to 16, and LW from 2 steps to 5. Built as three Basic flows instead, the window stays at 7.

Date checks compare UTC dates: {{now}} is UTC, and our test flows logged it with +0000. That matches your own date wherever 09:00 local falls on the same UTC day: up to UTC+9, so not in Sydney or Auckland. This holds on the Basic tab too.

Every recipe

In Jira Service Management, set the request type in the Create work item action. A work item cloned by Automation does not get one (JSDCLOUD-14350), and people on that ticket report that the customer then cannot see it in the portal. Need a description for the ticket? Our free Jira issue template generator writes one. To make every request of a type start the same way, see our guide to request templates in Jira Service Management.

• Every trigger run is a step, even when it finds nothing. A scheduled flow with a JQL search every 15 minutes costs about 2,922 steps a month before it does anything. Every 5 minutes, about 8,766. Hourly, about 730. Estimated When our test flow’s search found nothing, its trigger still ran, and the run stopped there.
• Every condition that runs is a step, also when it says no.
• Every action is a step. So is each branch and loop, every time it runs.
• Set to recur makes one flow per work item. Each is named “Clone on a schedule” and labelled “Recurring”, and each run counts.
• Flows that run when a work item is created run for every new request, however it arrives.
• A scheduled flow that fails 10 times in a row turns itself off. A recurring ticket can stop without anyone noticing.
• Sandboxes count. Steps in a sandbox come out of the same pool, and the usage dashboard does not show them apart.
• What does not count: throttled runs, and Rovo steps, which use Rovo credits instead.

To see where yours go, open Jira’s Automation page and its Usage tab. It shows the month’s total steps, marked Estimate, and a High usage flows table with columns for each flow’s runs and Automation steps. Its only date filter is a whole month. Observed On our development site, in a space’s settings and in global Automation, it still showed 0 steps at nine checks up to 20:43 UTC on 20 October 2026, 2 hours 48 minutes after the first of our 28 test runs. We don’t know why. Each flow’s audit log showed which steps ran in each of those runs.

Let the customer own the schedule. Space admins and Jira admins build flows. Set to recur is open to anyone with view and edit permission on the work item, unless a Jira admin turns that off for non-admins. Portal customers have neither. A customer who wants a monthly request has to ask an agent, and the agent’s flow owns it.

Keep each customer’s clock. A flow runs on one clock, chosen by the admin who builds it: the Basic tab’s time zone, or UTC for a cron line (a time zone setting for cron, AUTO-1712, is Gathering Interest). Customers in five time zones need five flows, and no customer can pick or change their own.

Move a run off a closed day. Business days ignore holidays (AUTO-971, Gathering Interest). Moving a run to the next open day has no simple recipe: it takes a check on every day the run could move to, with your list of dates in it, in every flow, kept by hand.

Copy with the request type. A clone made by Automation gets none. Set to recur works by cloning (its doc lists the clone action), so check the request type on its copies.

To be fair, three things Automation can do that people often say it cannot. Its Basic tab can keep 09:00 local through the clock changes: its preview does, though we have not run one across a change. It can skip dates you list, with one condition. And it can create a ticket on the 2nd business day without a daily check, with the three-day window.

• Admin- or agent-owned work. A monthly scheduled flow costs 2 steps a month, runs at 09:00 in the time zone its admin picks on the Basic tab, and needs nothing installed.
• Work after the ticket exists: assigning, transitioning, editing fields, notifying people.
• Jira work outside Jira Service Management. Our app only works in service desk portals.
• Sites where steps do not matter. If the Usage tab shows plenty of room, keep what works.
• Holiday calendars on the agent side. Repeating Issues for Jira says on its Marketplace listing that it re-schedules repeats that fall on non-working days. The Scheduler has project and global calendars of days off: its documentation says a scheduled issue that uses one is not created on those days. Its schedules are managed per project, by project admins or users they give access, with a wizard or a Quartz cron line.

And know what our app does not copy: files, participants and organisation sharing, forms after the first, and fields that pick a record, such as Affected services. The documentation lists what is not copied.

We make Recurring Requests & Templates for Jira Service Management. That is why this page exists, and why every number on it shows its source.

In version 3.5.0, portal customers schedule their own requests: daily, weekly, monthly or quarterly; a weekday such as the first Monday; a working day such as the second; or chosen days of the week. Each runs at the customer’s own time, in their own time zone, and stays there when the clocks change. The desk can mark closed days. A run on one moves to the next open day or is skipped, as the desk chooses. Customers see the next dates before they save. Each request is raised as the customer.

Its schedules run on Atlassian Forge, not on Automation, so they use 0 Automation steps. Most scheduler apps on the Marketplace run outside Automation too, and several say so on their listings, so their schedules also use 0 steps. Ours differs in who owns the schedule: the portal customer. Each request it raises is a new request, so your own flows that run when a work item is created still run and count, as they would for a request typed by hand.

Scheduling is off until an admin turns it on for the project, and the admin sets the limits: request types, the shortest gap, how far ahead, and how many schedules each customer may have.

It is free for up to 10 agents and paid above that. The prices are on its Marketplace listing. On steps alone it will rarely pay for itself. The reasons to use it are who owns the schedule, each customer’s own time zone, and closed days.

1. Look at your usage. In Atlassian Administration, Insights → Platform usage shows steps against the pool. In Jira, the Automation page’s Usage tab lists flows by steps.
2. Decide about extra usage. It is on by default for most organisations. Off means every flow stops at 100% until the reset, or until you add a step pack. A monthly extra usage limit caps the money instead, but reaching it can stop metered features too. Prepaid step packs are a third way to add room. Atlassian marks some kinds of pack as coming soon.
3. Know who gets the alerts at 80% and 100%: organisation or billing admins, depending on the page. Make sure someone reads that inbox.
4. Find polling flows. A scheduled flow that runs every few minutes costs a step each time, even when its search finds nothing. Slow it down, or move it to an event trigger.
5. Find Set to recur flows. Filter flows by the label “Recurring”. A Jira admin can stop non-admins creating more under Global automation → Global configuration.
6. Swap daily checks for a Basic monthly schedule, a three-day window or LW where the job allows it. Automation accepted LW in our test, but we have not yet seen it fire, so watch its first run.
7. Look for scheduled flows that keep failing. At 10 failures in a row they turn themselves off.
8. Test in a sandbox sparingly. Its steps come out of the same pool.
9. Watch for Atlassian’s message with your own organisation’s billing start date.

How we worked it out. We read the Atlassian pages below on 20 October 2026. Ten of them we had also copied on 10 October, and nothing the calculator uses had changed on those. The other eleven, among them the Jira, Confluence, Teamwork and Jira Product Discovery pricing pages, we read for the first time on 20 October. A schedule’s steps a month are runs × (1 + conditions) + tickets × (1 + extra actions). A cron recipe kept at 09:00 local with the DST-safe form is runs × (4 + conditions) + tickets × (1 + extra actions); a recipe on the Basic tab keeps its count. A failed condition ends the run: we assumed it, and our test’s audit log showed it.

The calendar. An average month has 30.436875 days, 21.740625 weekdays, 4.348125 weeks, and 5.436875 days from the 26th on. These are exact averages over the 400-year Gregorian cycle, 2001 to 2400, counted day by day. The windows were checked against every month in that cycle.

Estimated, Observed or Measured. Every step count on this page is Estimated: worked out from Atlassian’s rules, not read off a meter. Where our test showed which steps ran in a run, or what Automation’s screens offer, we say Observed. A count becomes Measured, with the date, only when the Usage tab shows it.

What we tested

On 20 October 2026 we built 12 test flows in one service space on our own development site. Each had a scheduled trigger with a cron line, a {{smart values}} condition where the recipe needs one, and a Log action in place of Create work item, so nothing was created or changed. They ran 28 times: 25 by hand, 3 on schedule. For every run we read the flow’s audit log, which lists the steps that ran. We also read the Basic tab’s options and its preview of the next 10 runs, without saving a Basic schedule or choosing more than one day of the week on it. The Usage tab still showed 0 steps at 20:43 UTC, 2 hours 48 minutes after the first run, so no count here is read off the meter yet. We don’t know why, and we have not checked which plan our development site’s Automation usage is counted under. We will look again and say so below. All 12 flows were turned off afterwards. We publish no screenshots: they show our site’s private data.

The data file. automation-step-rules.json, version 2026-10-21, holds every rule, allowance and recipe on this page, each with its source and the date we checked it, and what our test showed. The calculator and every table here are built from it. It is under CC BY 4.0: use it, with credit to Eriksen Labs and a link to this page.

Reviews. 2 November, 1 December, 4 December, then the first Monday of each month. Each review re-reads the pages, bumps the file’s version and adds a line below.

Privacy. This page runs no tracking of its own, and the calculator sends nothing. The site counts page views with Cloudflare Web Analytics, which sets no cookies. The Marketplace button counts one click for this page, with no IP address, cookie or identifier. See the privacy policy.

Sources

• How is your automation usage calculated (checked 20 Oct 2026, last changed 4 Sep 2026)
• Atlassian Automation (licensing FAQ) (checked 20 Oct 2026)
• Usage-based pricing (licensing FAQ) (checked 20 Oct 2026)
• Manage extra usage for a meter (checked 20 Oct 2026)
• How usage-based pricing works (checked 20 Oct 2026)
• Service Collection pricing (checked 20 Oct 2026)
• Jira pricing (checked 20 Oct 2026)
• Confluence pricing (checked 20 Oct 2026)
• Teamwork Collection pricing (checked 20 Oct 2026)
• Jira Product Discovery pricing (checked 20 Oct 2026)
• Permissions required to manage automation flows (checked 20 Oct 2026, last changed 29 Apr 2026)
• Jira automation triggers (checked 20 Oct 2026, last changed 29 Apr 2026)
• Automation service limits (checked 20 Oct 2026, last changed 29 Apr 2026)
• Schedule work items to recur using automations (checked 20 Oct 2026, last changed 29 May 2026)
• Automation smart values: date and time (checked 20 Oct 2026, last changed 21 Aug 2026)
• Schedule work items creation with Jira Cloud automation (KB) (checked 20 Oct 2026, last changed 25 Sep 2025)
• How to exclude a specific date without using complicated Cron expressions (KB) (checked 20 Oct 2026, last changed 5 Nov 2025)
• AUTO-1712: Include timezone support for Cron jobs (Gathering Interest) (checked 20 Oct 2026, last changed 2 Jul 2026)
• AUTO-971: Define non-working days and public holidays for BusinessDays (Gathering Interest) (checked 20 Oct 2026, last changed 18 Sep 2026)
• JSDCLOUD-14350: Cloning with Automation does not set the Request Type (Gathering Interest) (checked 20 Oct 2026, last changed 20 Oct 2026)
• JRACLOUD-94173: Monthly and quarterly options for recurring work items (Gathering Interest) (checked 20 Oct 2026, last changed 15 Oct 2026)

Changelog

• 21 October 2026 (rules file 2026-10-21). First public version. Before publishing we re-checked every rule against Atlassian’s pages on 20 October 2026, and tested the recipes on our development site the same day (see What we tested). From the re-check, compared with our 10 October draft: Confluence’s user cap is 250,000 per site, not 100,000; the cap is now per product. Added the Free plans’ user caps, extra usage being on by default, sandbox steps counting, and scheduled flows turning off after 10 failures in a row. The DST-safe check uses format("HH"), which Atlassian documents, instead of .hour, which it does not. Atlassian’s “exclude a date” KB skips times of day, not dates, and is cited for that only. From the test: only a cron line runs in UTC. The Basic tab has its own time zone, and its preview keeps 09:00 local, so the DST-safe form and its extra steps now apply only to recipes that need a cron line. The first Monday or last Friday is a Basic monthly schedule at 2 steps, and the 2nd-business-day window can be three Basic monthly flows at the same 7 steps. Automation accepted the Quartz forms MON#1, 6L, LW and 1W, so they are listed, with LW (2 steps) as the cheapest last-business-day recipe; they had not come due before the test ended. A failed condition is labelled Success on our site, not NO ACTIONS PERFORMED. The audit log’s counts of what ran in each run are marked Observed. The Usage meter had not shown the test runs, so every step count stays Estimated.

Corrections

None yet. If something here is wrong, email [email protected]. We will fix it and say so here.