Blog · 16 September 2026

Jira cron expression: the syntax, the traps, and what it cannot say

A Jira cron expression is a Quartz-style string of seven space-separated fields that starts with seconds, not minutes, which is why an expression copied from a Linux crontab usually does not do what you expect when you paste it into Jira. Atlassian documents the field order as second, minute, hour, day-of-month, month, day-of-week and an optional year, and you can use one in a filter subscription or in an automation rule's scheduled trigger. This guide gives you the field table, the special characters, expressions you can copy, the two numbering traps that fire silently, and the three kinds of schedule no cron expression can express — where the answer is to stop writing cron rather than to write better cron.

The short verdict #

• You need a fixed clock-time schedule — 6am on the first of the month? Cron is the right tool and Jira Automation runs it for free inside your plan.
• You copied the expression from a server crontab? Add a leading 0 for seconds and re-read the day-of-week numbering before you trust it.
• You need "skip it if it lands on a public holiday", or "move it to the previous working day"? No cron expression can say that, and what a cron expression cannot say is the section to read.
• You are writing your fifth expression and nobody else on the team can read them? That is the point at which a schedule builder pays for itself — Recurring Work Items for Jira has no cron field at all, and will import the rules you already wrote.

The Jira cron expression format #

Atlassian's own documentation for Jira Cloud (checked September 2026) gives these fields, in this order:

The first field is seconds. A standard five-field crontab line — 30 6 1 * * — is missing that field, so Jira reads your minute as a second, your hour as a minute, and the whole thing fires at a time nobody chose.

And these are the special characters:

Atlassian's worked example is 0 15 8 ? JAN MON 2014, which it reads as 8:15am every Monday during January 2014.

Expressions you can copy #

Read them as one sentence each: at second 0, at minute 30, at hour 9, on no particular day-of-month, in every month, on Monday through Friday.

Where a cron expression works in Jira Cloud #

The two numbering traps #

Sunday is not the same number everywhere. Quartz — which is what Jira reads — counts Sunday as 1, so Friday is 6. Plain Unix cron counts Sunday as 0, so Friday is 5. An expression carried across from a crontab with a numeric day-of-week is therefore off by one day, and it fires happily on the wrong day for months before anybody connects the ticket to the expression. Write weekday names instead of numbers — MON, FRI — because the names are unambiguous in both dialects.

? and * are not interchangeable. Day-of-month and day-of-week cannot both be specified, so exactly one of them must be ?. 0 0 8 * * MON asks for every day and Mondays; 0 0 8 ? * MON is the one you meant.

What a cron expression cannot say #

This is the part that decides whether you should be writing cron at all. Cron is a clock, and three very ordinary scheduling requirements are not clock questions:

• Public holidays. There is no holiday field. W finds the nearest weekday, which knows about Saturdays and Sundays and nothing about Christmas, your company shutdown, or a regional holiday that moves each year. A monthly access review that lands on a holiday is created on the holiday.
• "Every two weeks." Cron steps are within a field, not across months — 0 0 8 ? * MON/2 does not mean every other Monday — it starts at Monday and takes every second weekday from there, so it fires Monday, Wednesday and Friday. Fortnightly is one of the schedules people most often think they have written and have not.
• What should happen when a run is missed. If nothing fires — an outage, a rule switched off, a limit reached — cron has no opinion. The next occurrence comes round and the skipped one leaves no trace.

A cron expression you wrote and an approximation of it are not the same rule, and the approximation is the one that fires at the wrong time for years without anybody noticing.

What a scheduled rule costs to run #

Cron itself is free, but the rule around it is metered. Atlassian meters automation in steps — the trigger, each condition, branch, loop and action counts once every time it runs — with monthly allowances of 150 per subscription on Free, 400 per user on Standard, 750 on Premium and 1,000 on Enterprise, pooled across your organisation's Atlassian apps (Atlassian's usage documentation, September 2026). With extra usage switched off, flows stop at 100% until the allowance resets; with it on, overage is $0.50 per 1,000 steps. A recurring create rule spends at least two steps every firing. The full arithmetic is in Jira Automation pricing.

Apps that take a cron expression #

Listings read September 2026. All three of the first group are reasonable answers if cron is genuinely what you want — an expression is compact, portable, and there is no ambiguity about what it means once you can read it.

Who should stay with Jira Automation #

Stay where you are if your recurring rules are few, your automation allowance has room, and the schedules really are clock schedules. Cron covers every fixed calendar shape you are likely to need, and a scheduled rule can do things a purpose-built scheduling app cannot: Atlassian's trigger documentation notes that a scheduled flow can also take a JQL query and act on every work item it matches, which is a different job from creating one ticket on a cycle. Paying for an app to do what a free rule already does correctly is not an upgrade.

The case for leaving is narrower than the marketing suggests, and it is usually one of three things: the step allowance, the holiday problem, or the fact that nobody except the person who wrote the expression can safely change it.

If you already wrote the cron expression #

Rewriting a dozen schedules by hand is the reason most teams stay on a tool they have outgrown, so Recurring Work Items for Jira reads them instead. Export the automation rule from Jira, paste it into Import from Automation on the project page, and the import reports what each rule would become before it writes anything.

It reads both dialects — a five-field crontab line and Jira's six or seven-field Quartz expression — and it resolves the Sunday numbering for you, naming the weekday it read so you can check it. Where an expression says something the app cannot say exactly, the import refuses that rule by name rather than rounding it: an expression that runs several times a day, one restricted to certain months, one naming several days of the month. A refusal you can read is the right outcome there, because a schedule quietly rounded to the nearest thing the app supports is the failure mode this whole article is about.

What you get in place of the expression is a pattern picker — every day, every week on chosen weekdays, or every month on a day or an nth weekday — plus the one thing cron has no field for: a working-day policy per rule. When an occurrence lands on a weekend or on a holiday in the project's own calendar, the rule can run anyway, roll forward to the next working day, roll back to the previous one, or skip that occurrence entirely. Every run, including the skipped ones, is on the rule's history.

Where to go next #

• Jira recurring tasks: Automation, cloning, or a scheduling app? — the three routes compared, with what each costs.
• Jira Automation pricing — what a step is and what a recurring rule spends.
• Dynamic titles and dates — the token vocabulary for naming each cycle's issue.

Sources: Atlassian's cron expression documentation for Jira Cloud filter subscriptions, its automation trigger documentation and its automation usage documentation; Marketplace listings for The Scheduler and Issue Scheduler. All read September 2026 — plans and app features change, so check the current page before you budget on a number.